♻️ sync owner migration and facade thinning

docs/api/async-logger-is-closed.md

@@ -2,7 +2,7 @@
 name: async-logger-is-closed
 group: api
 category: async
-update-time: 20260614
+update-time: 20260707
 description: Read whether the async logger has entered closed lifecycle state and should no longer be treated as a normal active enqueue target.
 key-word:
     - async
@@ -36,11 +36,11 @@ Detailed rules explaining key parameters and behaviors
 - `close(...)` sets the closed state immediately.
 - `shutdown(...)` also results in a closed logger by the end of its lifecycle flow.
 - A closed logger should no longer be treated as a normal active enqueue target.
-- This helper is only a direct read of the current `is_closed` ref; it does not wait for drain completion or clear any other state.
+- This helper is derived from the current lifecycle phase rather than from an independent closed flag ref.
 - This helper reflects lifecycle state only and does not indicate whether the worker is still draining.
 - `is_closed()` becoming `true` does not imply the logger reached a clean success state. Failure flags, retained `last_error()`, and remaining backlog-related counters can still reflect the earlier worker outcome.
-- After shutdown on a worker-failure path, `is_closed()` can therefore be `true` while backlog cleanup remains runtime-dependent: native-worker runtimes can convert leftover pending records into dropped ones, while compatibility runtimes can still report the remaining queue entries as pending.
-- Exact post-close logging behavior is runtime-dependent: compatibility runtimes can short-circuit before patch and enqueue work, while native-worker runtimes may still build and patch a record before the closed queue rejects it, so `is_closed()` should be read as a lifecycle signal rather than a full enqueue-policy contract.
+- After shutdown on a worker-failure path, `is_closed()` can therefore be `true` while retained failure state still remains visible under `phase=closed_failed`.
+- Late log attempts are rejected in the shared async log path after closure, so `is_closed()` now aligns with a stable post-close enqueue rejection contract.
 
 ### How to Use
 
@@ -74,7 +74,7 @@ e.g.:
 
 - If callers need to know whether the worker is still active, they should also inspect `is_running()`.
 
-- If callers need to know whether closure also prevented later log attempts on the current backend, they must interpret this together with the active runtime behavior rather than this flag alone.
+- If callers need to know whether the logger is also terminal or rerunnable, they should inspect `state().terminal` or `state().can_rerun`.
 
 - Closing a logger does not by itself reset `has_failed()` or `last_error()`.