📝 clarify application helper visibility

docs/api/build-application-logger.md

@@ -36,6 +36,7 @@ Detailed rules explaining key parameters and behaviors
 - This API delegates to `build_logger(...)` directly.
 - The embedded config still goes through the normal 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 builder does not hide any queue, drain, flush, or file runtime helper methods.
+- The configured runtime helper surface is therefore preserved and 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 this alias-oriented entrypoint when application boot code wants an app-specific name without changing the underlying configured runtime logger surface.
@@ -57,6 +58,8 @@ In this example, the application facade builds the same configured runtime logge
 
 And any queue/file/runtime helpers selected by the config remain directly available on the returned alias value.
 
+And unlike `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 the facade does not wrap or narrow the underlying `ConfiguredLogger`.
 
 #### When Need A Per-call Target Override After App-oriented Build