Improve bounded MPSC throughput for inline 1 KiB messages #401

The reproducible gap is four producers and one consumer on four Tokio runtime workers, using 64 queue slots. Each timed batch transfers 16,384 inline [u8; 1024] values. Both four-library launches put Asyncband fourth.

Apple M4 Max, macOS arm64, rustc 1.101.0-nightly. Each cell gives rank, elapsed time relative to Asyncband and the whole-batch median over 10 interleaved runs. Lower is faster. Ecosystem measurements

With topology and batch count fixed, Asyncband and Tokio took 23 and 39 ms for usize, 304 and 78 ms for inline 1 KiB, and 106 and 89 ms for the same bytes in a Box. Calling reserve before every Asyncband send still took 303 ms for inline values. Stack samples showed mutex waits and memmove in the send path. In another matched run, changing only the internal lock reduced Asyncband from 306 to 189 ms, with Tokio at 83 ms. The queue moves values into and out of a shared VecDeque under its state lock.

First contribution

Reproduce the inline row, then profile send and receive separately with inline and boxed payloads. Look for copies or time under the queue lock. Validate a candidate with ordinary usize traffic, a full queue and cancelled reservations. Preserve delivery order, backpressure and the exact requested capacity.

cargo x bench --bench ecosystem -- mpsc/bounded/tasks-4p1c-cap64-4w-inline1k --rounds 26 --repeat 10 --raw

The one-producer usize case at capacity 1024 is a variability control at 430 fixed rounds. Flume won its original run (210 ms vs Asyncband's 366 ms), and Asyncband won the repeat (194 ms vs 213 ms). It has a different payload and topology. Both four-library rankings

Performance tracking issue #396