docs(irtt-client): document caller-owned cadence

crates/irtt-client/AGENTS.md

@@ -127,7 +127,8 @@ remains anchored to before the send, on purpose, so the existing pre-send
 timeout/overflow/no-send contract is unchanged. Only the *measurement*
 `sent_at` moved to after the send. A `WouldBlock` `try_send` (Tokio) never
 samples a `sent_at`, never calls `finalize_probe_commit`'s matching
-`commit_probe_sent`, and never advances the machine or schedule; each retry
+`commit_probe_sent`, and never advances the machine; the managed runner advances cadence only
+  after an accepted send; each retry
 gets its own fresh pre-send anchor, and only a successful attempt's anchor
 and `sent_at` are ever retained.
 

crates/irtt-client/README.md

@@ -22,6 +22,13 @@ binaries are built on.
   runtime, and `BlockingManagedClient` for synchronous callers, which owns its
   own dedicated current-thread runtime.
 
+`Client` and `AsyncClient` send one probe whenever called. They expose the
+negotiated parameters, pending-probe status, and timeout deadlines; callers
+own cadence and run duration. The managed driver provides fixed cadence,
+missed-slot handling, finite runs, and staggered or burst pacing. Low-level
+`EchoSent` events leave `scheduled_at` and `timer_error` absent; the managed
+driver supplies those schedule measurements.
+
 Tokio stays optional: the default build has no runtime and no Tokio
 dependency at all.
 

crates/irtt-client/src/lib.rs

@@ -18,7 +18,10 @@
 //! wants full control over its own event loop, should start from. With the
 //! `tokio` feature, `AsyncClient` provides the corresponding low-level Tokio
 //! adapter for a caller that owns a runtime and drives socket readiness
-//! itself. [`managed`] sits above both: `ManagedClientTask` /
+//! itself. Both adapters send one probe whenever called; callers own cadence
+//! and run duration, using `negotiated_params()` after Open. [`managed`] owns
+//! negotiated-interval scheduling, finite runs, and staggered/burst pacing:
+//! `ManagedClientTask` /
 //! `ManagedClientHandle` (`tokio` feature) run and control one or more
 //! targets under a Tokio runtime, and `BlockingManagedClient` (`tokio`
 //! feature) wraps that in a synchronous owner backed by its own dedicated