♻️ sync owner migration and facade thinning

docs/api/async-logger-close.md

@@ -2,7 +2,7 @@
 name: async-logger-close
 group: api
 category: async
-update-time: 20260614
+update-time: 20260707
 description: Close the async logger queue immediately and optionally convert current pending backlog into dropped records before queue closure.
 key-word:
     - async
@@ -35,13 +35,14 @@ pub fn[S] AsyncLogger::close(self : AsyncLogger[S], clear? : Bool = false) -> Un
 Detailed rules explaining key parameters and behaviors
 
 - `close(...)` marks the logger as closed immediately.
+- If a worker is still active when `close(...)` runs, the lifecycle phase moves into the closing path first and only settles into a terminal closed phase after worker exit.
 - `clear=false` closes the queue without explicitly abandoning pending records in the helper itself.
 - `clear=true` counts pending records as dropped and resets `pending_count` to `0` before closing the queue.
 - This helper does not itself wait for the worker to finish.
 - `close(...)` also does not change `has_failed()` or `last_error()`; it is a closure primitive, not a failure reset API.
 - Because this is a low-level close primitive, it does not first run `wait_idle()` or apply the runtime-dependent fallback logic used by `shutdown()`.
-- After closure, later log attempts do not add new pending or dropped counts, but backend behavior can still differ before the closed queue rejects the record.
-- In the current direct coverage, compatibility runtimes short-circuit before patch-path work on late log attempts, while native-worker runtimes may still build and patch the record before the closed queue rejects it.
+- After closure, later log attempts are rejected in the shared async log path before record build, patch, or filter work starts.
+- That means post-close late logs no longer add pending or dropped counts, and they no longer trigger patch/filter side effects on one backend but not another.
 
 ### How to Use
 
@@ -72,7 +73,7 @@ e.g.:
 
 - If `clear=false`, pending records may still exist after closure until worker drain or later cleanup resolves them.
 
-- If callers perform late log attempts after closure, backlog counters still stay unchanged, but patch-path side effects are runtime-dependent and should not be treated as a portable post-close contract.
+- If callers perform late log attempts after closure, backlog counters still stay unchanged and patch/filter side effects stay skipped.
 
 - If callers need graceful waiting for drain completion, `shutdown()` is usually the better API.