📝 clarify library async run restart semantics

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

@@ -36,6 +36,7 @@ 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.
@@ -76,6 +77,8 @@ 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