📝 clarify async runtime mode probe

docs/api/async-runtime-mode.md

@@ -40,6 +40,7 @@ Detailed rules explaining key parameters and behaviors
 - `async_runtime_state()` packages this mode together with the current background-worker capability into one `AsyncRuntimeState` snapshot.
 - In the current backend implementations, `NativeWorker` pairs with `background_worker=true` and `Compatibility` pairs with `background_worker=false`.
 - Concretely, the native runtime entrypoint returns `native_worker_async_runtime_mode()`, while the compatibility stub returns `compatibility_async_runtime_mode()`.
+- The enum is therefore selected directly by the active backend helper on each call rather than read back out of a cached runtime snapshot object.
 - This API is intentionally small and useful for lightweight branching.
 - The mode result describes runtime behavior only; it should not be read as proof that every backend has been equally re-verified in the current release cycle.
 
@@ -73,6 +74,8 @@ In this example, the output becomes a stable string instead of an enum pattern-m
 e.g.:
 - This API does not have a normal runtime failure mode; it reflects the compiled backend behavior.
 
+- If callers need the current mode paired with the matching worker-support flag, prefer a fresh `async_runtime_state()` call instead of combining `async_runtime_mode()` with an older saved runtime snapshot.
+
 - If you need worker support as a direct boolean, use `async_runtime_supports_background_worker()` instead.
 
 ### Notes