Say what the campaign's throughput number measures

[dhruvl]

The green sweep recorded 300.1 seeds/s on 2026-08-01 and 263.1 on 2026-08-04,
about 12% apart, with four merges in between (#25 inline executor, #26
loopback streams, #27 write-side flow control, #28 TLS). Profiling and
bisecting the window says none of them is what paid, so the benchmarks README
now says what that number is and is not.

Wall clock cannot settle it on a fanless laptop: five interleaved 2,500-seed
runs of each merge commit spread 230-265 seeds/s within every commit. CPU time
summed across the ten workers is contention-proof, and by that measure a seed
costs the same across the whole window - 32.77 seeds/CPU-second at #24 against
32.49 at main, with every tree's own spread under 1%. Re-running the sweep
back to back agrees: main covers 20,000 seeds at 262.8 seeds/s today, while
the #24 tree that recorded 300.1 manages 259.2 in the same sitting.

The two merges that do touch the per-packet path cost nothing measurable.
Flow control's charge and credit are an attribute read and a return with the
switch off, ~150 calls a seed and 0.1% of profiled time; the widened stream
registry key is one more element to hash per dispatch. Both are invisible
against the 38.6% of a seed spent in the gc.collect() that run_until_complete
needs to surface an orphaned task's failure.

No source changes, so no recorded trace hash moves. Full suite green:
565 passed with -m "slow or not slow".