📝 consolidate logger API and async lifecycle guidance

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

@@ -3,7 +3,7 @@ name: library-async-logger-run
 group: api
 category: facade
 update-time: 20260613
-description: Start the LibraryAsyncLogger worker loop so queued records are drained to the underlying sink.
+description: Start the LibraryAsyncLogger worker loop by delegating to the wrapped async logger's run behavior.
 key-word:
     - async
     - library
@@ -36,7 +36,10 @@ Detailed rules explaining key parameters and behaviors
 - This method delegates directly to the wrapped async logger's `run()` behavior.
 - It starts the worker loop that makes accepted queued records reach the underlying sink.
 - Failure and lifecycle state are still tracked by the wrapped async logger.
+- Once a delegated `run()` call has actually started, it clears any previous `has_failed()` flag and stored `last_error()` string on that same wrapped logger before draining resumes.
 - The narrower library facade does not hide the need to explicitly activate queue draining.
+- If the worker fails, the wrapped async logger records that through its failure-state helpers, which still require `to_async_logger()` for inspection from library-facing code.
+- Unwrapping after a delegated `run()` exposes the same failure and backlog state that accumulated behind the facade; it does not create a second runtime view.
 
 ### How to Use
 
@@ -65,6 +68,8 @@ group.spawn_bg(() => logger.run())
 
 In this example, the caller decides when the worker begins instead of hiding that lifecycle step.
 
+And the started worker loop is still the same wrapped async logger runtime rather than a separate library-specific execution path.
+
 ### Error Case
 
 e.g.:
@@ -72,8 +77,14 @@ e.g.:
 
 - If `run()` is never started, accepted records may remain queued and not reach the sink.
 
+- A later delegated `run()` attempt starts from a fresh failure flag and empty `last_error()` string on the same wrapped logger, even if an earlier facade-level run failed.
+
+- If callers need to inspect `is_running()`, `has_failed()`, or `last_error()` directly, they must unwrap first with `to_async_logger()`.
+
 ### Notes
 
 1. `LibraryAsyncLogger::new(...)` only constructs the facade; `run()` is what activates queue draining.
 
 2. Pair this API with `shutdown()` for a complete worker lifecycle.
+
+3. Use `to_async_logger()` first when operational code needs direct lifecycle or failure inspection in addition to starting the worker.