📝 clarify async facade projection aliasing

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

@@ -2,8 +2,8 @@
 name: async-logger-to-library-async-logger
 group: api
 category: facade
-update-time: 20260613
-description: Convert a full async logger into the narrower library-facing async facade without rebuilding the underlying async state.
+update-time: 20260614
+description: Convert a full async logger into the narrower library-facing async facade without rebuilding or detaching the underlying async state.
 key-word:
     - async
     - library
@@ -35,6 +35,7 @@ Detailed rules explaining key parameters and behaviors
 
 - This conversion does not rebuild the queue, sink, or runtime state.
 - Target, min level, async config, flush behavior, pending counts, and failure state are preserved because the same underlying async logger value is wrapped.
+- The original `AsyncLogger[S]` handle remains the same live logger. If caller code keeps that original value, later facade calls and later unwraps still observe the same shared queue, counters, sink helpers, and lifecycle mutations.
 - The returned facade keeps library-facing async operations including `log(...)`, `run()`, and `shutdown(...)`.
 - Async inspection helpers and broader composition APIs remain on the underlying `AsyncLogger[S]` and are intentionally hidden until `to_async_logger()` is used again.
 - If later facade-level `run()` or `shutdown()` calls record worker failure, leave backlog behind, or follow runtime-dependent shutdown cleanup rules, unwrapping later still exposes that same post-call state instead of a translated facade copy.
@@ -42,6 +43,7 @@ Detailed rules explaining key parameters and behaviors
 - When `S` itself exposes richer runtime helpers, projecting to the library facade does not strip those capabilities from the wrapped logger; they are still reachable after `to_async_logger()`.
 - When `S` is `RuntimeSink`, projection also preserves queued runtime state and file-backed runtime helper behavior behind the facade instead of replacing them with a library-specific copy.
 - Unwrapping later with `to_async_logger()` therefore exposes the same queue counters, failure snapshots, file state, and runtime file controls that the original async logger already carried.
+- That also means runtime sink mutations still alias in both directions: changing file append mode, auto-flush, rotation, or other sink helper state through a later unwrapped logger changes the same live runtime sink that the original `AsyncLogger[S]` already held.
 
 ### How to Use
 
@@ -68,6 +70,8 @@ ignore(public_logger.is_enabled(@bitlogger.Level::Info))
 
 In this example, the projection changes the exposed type only; it does not rebuild queue or lifecycle state.
 
+If `full` is still kept elsewhere, it continues sharing that same live runtime state with `public_logger`.
+
 ### Error Case
 
 e.g.:
@@ -83,6 +87,8 @@ e.g.:
 
 - Projection also does not normalize richer runtime sink state; if the original async logger already carried queued runtime data or file-backed helper state, a later unwrap still exposes that same live state.
 
+- Projection does not create an isolated wrapper copy. If callers keep the original `AsyncLogger[S]`, then later facade-level writes, shutdown, or sink-helper mutations still affect that original handle too.
+
 ### Notes
 
 1. Use this when package boundaries should avoid exposing the full async logger type.