[rokadepiyush49-rgb]

Summary

Add the controls #402 asks for to the no-backpressure broadcast comparison: a TokioArc adapter that publishes a fresh Arc<usize> per message, a one-reader drain, and a drain of four subscriptions on a single thread. Together they separate the Arc<T> that shared receives return from contention between receivers.

Apple M4 (macOS, Rust 1.94.1), median of ten interleaved runs. Lower is faster.

Scenario	Asyncband	Tokio	Tokio + Arc	async-broadcast
try-roundtrip	257 ms	104 ms	255 ms	231 ms
ready-roundtrip	240 ms	128 ms	257 ms	217 ms
publish-4p-drain-1r	253 ms	92 ms	284 ms	206 ms
drain-1r (new)	290 ms	152 ms	262 ms	262 ms
sequential-drain-4r (new)	293 ms	140 ms	248 ms	283 ms
drain-4r	296 ms	56 ms	79 ms	236 ms

The single-receiver gap to Tokio is almost entirely the per-message allocation that the shared Arc<T> contract requires: once Tokio pays for it, the rows are within about 10% and Asyncband leads two of them. Without contention, reading four subscriptions is also close (sequential-drain-4r, 0.84×). The remaining gap is contention: with four receiving threads Asyncband takes 296 ms against 79 ms, because every read advances its cursor under the one channel lock while Tokio's receivers read slots in parallel.

This PR changes no library code. Spinning briefly before blocking on the channel lock made drain-4r about three times slower (819 ms). Reading ahead into each receiver would reduce lock traffic but would change what retained_message_count reports and release bounded capacity early, so closing the gap looks like a backlog design decision rather than a local fix.

Refs #402.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.