refactor: use auto-reset events for drain notifications

[tisonkun]

Summary

Demonstrate replacing the two watch<()> notifications in MutationGate and ShardControl with AutoResetEvent from apache/asyncband#310. The event prompts a recheck of the existing mutation count, drain generation, or failure state; synchronous waiters continue to use their condition variables.

MutationDrainGuard excludes concurrent drains and remains held across every asynchronous shard wait, so each event has at most one asynchronous observer. Retained signals cover completion between checking the predicate and registering a wait. Signals left by cancelled waits or older generations only cause an extra predicate check. Notifications still occur after releasing state locks.

This removes watch subscriptions, unused values/versions, and sender-lifetime error handling. It targets the drain path; no throughput improvement is claimed. Multiple independent asynchronous observers would require reconsidering the primitive.

Design Notes

Cargo.toml and Cargo.lock pin the implementation at 085390437eba05a76efdcfd7e4388b1ea0023dbc in https://github.com/tisonkun/asyncband.git. A matching [patch.crates-io] in .cargo/config.toml keeps package verification on that revision when Cargo normalizes the dependency to a registry version. CI builds and verifies the generated package with the unreleased implementation; the source policy allows this repository for the demonstration.

Before merging, switch to the released Asyncband version containing apache/asyncband#310 and remove the temporary Git pin, Cargo configuration patch, and Git-source allowance.

Validation: cargo x check, cargo x test (including extended tests), and the complete cargo x lint workflow passed. Package metadata confirms that the generated package resolves Asyncband to the pinned Git revision. Deterministic tests cover exclusive drains, cancellation after signal assignment, retries, and stale drain generations.