perf(broadcast): reclaim the backlog in proportion to messages, not receivers

[ariesdevil]

Summary

Follow-up optimizations to #253.

• Scale broadcast backlog reclamation with the number of messages released rather than the number of subscriptions: each retained slot now carries a cursor count (with caught-up receivers tallied separately), so receive/remove_receiver update two counters and reclaim pops the zero-count prefix instead of scanning every cursor under the channel lock.
• Keep notify-all wake batches on the stack: WakerBatch stores up to 32 wakers inline (MaybeUninit) before spilling to a single heap allocation, and the broadcast, watch, and barrier publish paths fill it in place through the new WakerSet::drain_into, avoiding both the per-publication allocation and moving the 552-byte batch between frames.

Trade-off: retained slots grow from 8 to 16 bytes.

Benchmarks

Median of 100 samples, back-to-back A/B runs of broadcast::mpmc on the same host (baseline = #253 merge commit):

Benchmark	Baseline	After	Δ
drain_with_receivers peak 256, live 1	100.1 ns	29.0 ns	−71%
drain_with_receivers peak 256, live 32	298.6 ns	231.1 ns	−23%
try_send_and_drain_fanout 32 receivers	303.9 ns	232.4 ns	−23%
drain_with_receivers peak 32, live 1	34.4 ns	29.0 ns	−16%
deliver_to_receiver_batch 8	546.1 ns	525.5 ns	−4%
deliver_to_receiver_batch 32	1582 ns	1613 ns	≈ (noise)
try_send_and_try_recv (single receiver)	26.4 ns	32.3 ns	+5 ns
drain_with_receivers peak 1/8, small live sets	26–70 ns	29–74 ns	~+3 ns

The peak-256-live-1 case shows dropped receivers no longer cost anything: reclaim touches only the slots being released, never the subscription arena.