✅ cover application async builder queue path

docs/api/build-application-async-logger.md

@@ -38,6 +38,7 @@ Detailed rules explaining key parameters and behaviors
 - This API delegates to `build_async_logger(...)` directly.
 - That means the embedded `LoggerConfig` is built first through the normal synchronous config path before the outer async layer is applied.
 - Any optional synchronous queue layer and runtime-sink controls chosen by `build_logger(config.logger)` remain active under the returned logger.
+- In particular, a sync queue configured on `LoggerConfig.queue` is preserved inside the wrapped `RuntimeSink` variant instead of being stripped away by the application alias.
 - Because the result is only the `ApplicationAsyncLogger` alias over `AsyncLogger[@bitlogger.RuntimeSink]`, this builder does not hide any async helpers or introduce a wrapper layer.
 - The returned logger keeps the full async lifecycle and state helper surface directly, including helpers such as `run()`, `shutdown()`, `pending_count()`, `dropped_count()`, `state()`, `wait_idle()`, `has_failed()`, and `last_error()`.
 - It also keeps the same failure/reset and runtime-dependent post-close behavior documented on the underlying runtime-sink async logger.

docs/api/parse-and-build-application-async-logger.md

@@ -39,6 +39,7 @@ Detailed rules explaining key parameters and behaviors
 - Both the embedded sync logger config and async queue/runtime config are validated by the parser layer.
 - The embedded `LoggerConfig` is then built through the normal synchronous config path before the outer async layer is applied.
 - Any optional synchronous queue layer and runtime-sink controls from the parsed `logger` section remain active under the returned async logger.
+- That includes preserving a parsed sync queue configuration inside the resulting `RuntimeSink` variant rather than collapsing it away during application-alias construction.
 - Because the result is the `ApplicationAsyncLogger` alias over `AsyncLogger[@bitlogger.RuntimeSink]`, this parse-and-build path returns the same underlying async logger value that `parse_async_logger_build_config_text(...)` plus `build_async_logger(...)` would produce, without narrowing the helper surface.
 - The returned logger keeps the full async lifecycle and state helpers directly.
 - Use `parse_and_build_library_async_logger(...)` instead when the same parsed runtime-sink result should be wrapped and narrowed for a library boundary.