Bring WaitGroup completion to parity with waitgroup #397

Completing a group with one pending observer took nearly three times as long as waitgroup 0.1.2 in the original comparison. Both adapters create a group, register the observer, drop the worker handles and poll to completion. The four-worker case drops four handles sequentially on the same thread.

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

The baseline maintains a participant count as well as Arc ownership. Even the first observer uses a locked, cancellable waker collection. A candidate shares allocation ownership across participants, stores the first waker inline and uses the collection for additional observers. In two launches the one-worker medians were 81 vs 97 ms and 86 vs 97 ms (Asyncband vs waitgroup). With four workers they were 119 vs 125 ms and 127 vs 124 ms. That ranking changed between launches. Candidate and raw samples in PR #395

First contribution

Run the command on 36ba6f2 and on the candidate in #395 on the same machine. Report the two completion rows on independent launches, ideally also on Linux. The candidate adds a four-observer drain case. Check its before/after result separately because its peers compose a different multi-observer mechanism.

cargo x bench --bench ecosystem -- waitgroup/ --repeat 10 --raw

The goal is repeatable parity or better on both original rows while preserving completion visibility, independent observers, cancellation and wakeups. Measurements and correctness review on #395 are both welcome.

Performance tracking issue #396