📝 consolidate logger API and async lifecycle guidance

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

@@ -3,7 +3,7 @@ name: parse-and-build-application-logger
 group: api
 category: facade
 update-time: 20260520
-description: Parse JSON logger config text and build the application-facing sync logger facade.
+description: Parse JSON logger config text and build the application-facing sync logger alias by delegating directly to the configured runtime logger parse-and-build path.
 key-word:
     - application
     - facade
@@ -35,9 +35,14 @@ pub fn parse_and_build_application_logger(
 
 Detailed rules explaining key parameters and behaviors
 
-- This API delegates to `parse_and_build_logger(...)`.
+- This API delegates to `parse_and_build_logger(...)` directly.
 - JSON parsing and config validation happen before the logger is built.
-- The returned logger keeps the same queue and file helper surface as other configured sync runtime loggers.
+- The parsed config still goes through the normal configured runtime logger build path, including runtime sink selection, optional queue wrapping, and timestamp application.
+- Because the result is only the `ApplicationLogger` alias over `ConfiguredLogger`, this parse-and-build path returns the same underlying configured runtime logger value that `parse_and_build_logger(...)` would produce directly, without hiding any queue, drain, flush, or file runtime helper methods.
+- That preserved configured runtime helper surface also remains directly exposed on the returned alias rather than being rebuilt or hidden behind an unwrap step.
+- The returned alias also keeps inherited `Logger` behavior such as `with_target(...)`, `child(...)`, and per-call `target=` overrides on `log(...)`.
+- That means `log(..., target=...)` can override the target for one write, while severity helpers such as `info(...)`, `warn(...)`, and `error(...)` continue to use the stored logger target unless a derived logger was created first with `with_target(...)` or `child(...)`.
+- Use `parse_and_build_library_logger(...)` instead when the same parsed configured logger result should be wrapped and narrowed for a library boundary.
 
 ### How to Use
 
@@ -54,6 +59,26 @@ let logger = parse_and_build_application_logger(
 
 In this example, parsing and runtime construction are combined into one facade call.
 
+And any queue/file/runtime helpers selected by the parsed config remain directly available on the returned alias value.
+
+And unlike `parse_and_build_library_logger(...)`, no `to_logger()` unwrap is required to reach that helper surface.
+
+The returned value also keeps the ordinary logger target semantics because this facade does not wrap or narrow the configured runtime logger result.
+
+#### When Need A Per-call Target Override After JSON Boot
+
+When parsed app configuration should keep the same direct target override behavior as the ordinary configured logger:
+```moonbit
+let logger = parse_and_build_application_logger(raw) catch {
+  err => return
+}
+logger.log(Level::Error, "boom", target="app.audit")
+```
+
+In this example, the emitted record uses `app.audit` for that call.
+
+And later `info(...)`, `warn(...)`, or `error(...)` calls still use the logger's stored target unless code derives another logger first with `with_target(...)` or `child(...)`.
+
 ### Error Case
 
 e.g.:
@@ -66,3 +91,5 @@ e.g.:
 1. Use this facade when application code wants a text-to-runtime entry point.
 
 2. Use `build_application_logger(...)` when the config is already typed as `LoggerConfig`.
+
+3. Use `parse_and_build_library_logger(...)` instead when text-driven construction should narrow the public sync logger surface for a library boundary.