Reduce first-waiter overhead in Semaphore permit handoff #400

On a fresh zero-permit semaphore, registering a pending request and handing it one permit took 232 ms versus 64 ms for Tokio over three million handoffs. The benchmark verifies that the waiter becomes ready and forgets the permit to return the semaphore to zero.

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. Supplemental measurements

Object lifetime explains much of the first row on this host. With the same three million handoffs, a fresh semaphore each round took 233 ms for Asyncband and 65 ms for Tokio. Reusing one across rounds gave 86 and 63 ms. Allocation counting found two allocations per fresh Asyncband handoff and zero for Tokio. After warm-up both reused instances had zero allocations per handoff. Asyncband's first waiter goes through the queue lock and arena. Tokio stores its waiter node inside the acquisition future. Tokio's pinned implementation

First contribution

Reproduce both lifetimes with the same zero-permit protocol, then isolate the queue's first allocation. A change should improve first registration and keep the reused case competitive. Check multi-permit ordering, cancellation after a partial or full grant, and absence of missed wakeups. PR #394 addresses acquisition-future size and is related work. PR #394

To run the supplemental peer_checks command below, save and run peer-checks.rb from the linked comment in a disposable checkout of 6102089. The benchmark and library sources match 36ba6f2. Generator and instructions

cargo x bench --bench primitives -- semaphore::acquire::handoff_permit --repeat 10 --raw
cargo x bench --bench peer_checks -- semaphore/ --repeat 10 --raw

Performance tracking issue #396