📝 clarify async dropped count shutdown split

docs/api/async-logger-dropped-count.md

@@ -36,6 +36,7 @@ Detailed rules explaining key parameters and behaviors
 - The counter increases when overflow policy discards records.
 - The counter can also increase when `close(clear=true)` or `shutdown(clear=true)` abandons queued records.
 - It can also increase when shutdown fallback logic converts remaining pending records into dropped records during a clear-close path.
+- After a worker failure short-circuits `wait_idle()`, that shutdown-fallback increase is runtime-dependent in the current implementation: native-worker shutdown can convert leftover pending records into additional dropped records, while compatibility shutdown can leave that closed-queue remainder visible in `pending_count()` instead.
 - Later log attempts against an already closed queue do not add to this counter by themselves.
 - This is a cumulative counter for the lifetime of the logger value.
 - Use this helper when you need a focused loss metric rather than a full `state()` snapshot.
@@ -72,6 +73,8 @@ e.g.:
 
 - If callers need to know why records were lost, they must interpret this metric together with overflow policy and shutdown behavior.
 
+- If `wait_idle()` returned early because the worker failed, `dropped_count()` may still stay unchanged on compatibility shutdown paths even though one leftover closed-queue item remains visible in `pending_count()`.
+
 ### Notes
 
 1. This helper reports record loss only; it does not explain the full logger state.