✅ cover library async failure flow

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

@@ -38,6 +38,7 @@ Detailed rules explaining key parameters and behaviors
 - Failure and lifecycle state are still tracked by the wrapped async logger.
 - 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
 

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

@@ -44,6 +44,7 @@ Detailed rules explaining key parameters and behaviors
 - In runtimes where shutdown waits for workers, the method then waits until the worker is no longer running before returning.
 - After a worker-failure short-circuit, native-worker backends can still convert remaining backlog into dropped records, while compatibility backends skip that extra forced-clear step.
 - The narrower library facade does not change any of these runtime-dependent shutdown rules; it only keeps the broader inspection helpers out of the direct public surface.
+- Inspecting the logger later through `to_async_logger()` reveals the same delegated shutdown result rather than a rebuilt or translated lifecycle snapshot.
 
 ### How to Use
 

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

@@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors
 - Queue state, sink wiring, target, min level, flush policy, and current failure/lifecycle state remain the same.
 - Use this when code needs wider async logger APIs outside the library facade.
 - This is the step required for helpers such as `pending_count()`, `dropped_count()`, `state()`, `wait_idle()`, `has_failed()`, `last_error()`, or broader composition methods that are intentionally hidden by `LibraryAsyncLogger[S]`.
+- It is also the step that exposes the real post-run or post-shutdown state after facade-level lifecycle calls, because those calls delegated to this same wrapped logger all along.
 
 ### How to Use