📝 align async facade builder docs

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

@@ -2,8 +2,8 @@
 name: build-application-async-logger
 group: api
 category: facade
-update-time: 20260520
-description: Build the application-facing async logger facade from an AsyncLoggerBuildConfig.
+update-time: 20260614
+description: Build the application-facing async logger facade from an AsyncLoggerBuildConfig through the sync-first async builder path.
 key-word:
     - application
     - async
@@ -36,6 +36,7 @@ pub fn build_application_async_logger(
 Detailed rules explaining key parameters and behaviors
 
 - This API delegates to `build_async_logger(...)`.
+- That means the embedded `LoggerConfig` is built first through the normal synchronous config path before the outer async layer is applied.
 - The returned logger keeps the standard async lifecycle and state helper surface.
 - Use this facade when application code wants a dedicated async app-level entry point.
 
@@ -57,6 +58,8 @@ let logger = build_application_async_logger(
 
 In this example, the app-facing async facade is built directly from typed config.
 
+And any configured synchronous runtime sink controls remain available through the returned `RuntimeSink`-backed async logger.
+
 ### Error Case
 
 e.g.:

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

@@ -36,6 +36,7 @@ pub fn build_library_async_logger(
 Detailed rules explaining key parameters and behaviors
 
 - This API builds the general async runtime logger and then wraps it in the narrower `LibraryAsyncLogger[@bitlogger.RuntimeSink]` facade.
+- The embedded `LoggerConfig` still goes through the normal synchronous config path first, so sink shape and any optional synchronous queue layer are already applied before the outer async layer is wrapped and then narrowed.
 - The result keeps async lifecycle operations such as `run()` and `shutdown()` while narrowing the public shape.
 - Async state helpers such as `pending_count()`, `dropped_count()`, `state()`, `wait_idle()`, and failure-status inspection remain on the underlying `AsyncLogger`, not on the returned facade itself.
 - `to_async_logger()` can be used to recover the underlying full async logger.

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

@@ -2,8 +2,8 @@
 name: parse-and-build-application-async-logger
 group: api
 category: facade
-update-time: 20260520
-description: Parse JSON async build config text and build the application-facing async logger facade.
+update-time: 20260614
+description: Parse JSON async build config text and build the application-facing async logger facade through the sync-first async builder path.
 key-word:
     - application
     - async
@@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors
 
 - This API parses async build config text first, then builds the async application facade.
 - 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.
 - The returned logger keeps the normal async lifecycle and state helpers.
 
 ### How to Use
@@ -54,6 +55,8 @@ let logger = parse_and_build_application_async_logger(
 
 In this example, text parsing and async logger construction happen in one facade call.
 
+And any configured synchronous runtime sink controls remain available through the returned `RuntimeSink`-backed async logger.
+
 ### Error Case
 
 e.g.:

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

@@ -36,6 +36,7 @@ pub fn parse_and_build_library_async_logger(
 Detailed rules explaining key parameters and behaviors
 
 - This API parses async build config text, validates it, builds the async runtime logger, and narrows it to the library facade.
+- The embedded `LoggerConfig` still goes through the normal synchronous config path first, so sink shape and any optional synchronous queue layer are already applied before the outer async layer is wrapped and then narrowed.
 - The resulting facade keeps async lifecycle helpers while exposing a smaller public surface.
 - Async state helpers such as `pending_count()`, `dropped_count()`, `state()`, `wait_idle()`, and failure-status inspection stay on the underlying `AsyncLogger`, not on the returned facade itself.
 - `to_async_logger()` can recover the underlying async logger when a wider API is required.