Add AsyncShardClaiming / AsyncCoordinationFacade to complete the async coordination surface

[coderabbitai]

Summary

With AsyncCoordinationBackend and AsyncRunManagement added in PR #148, the async coordination surface is nearly complete. The remaining gap is the claiming and facade layer:

• ShardClaiming (sync) lives in crates/gossip-coordination/src/facade.rs and provides claim_next_available backed by default_claim_next_available.
• CoordinationFacade (sync) composes RunManagement + CoordinationBackend + ShardClaiming.

Without async equivalents, async backends must either duplicate the scan/acquire loop or fall back to the blocking sync wrapper — neither of which is acceptable for production I/O-bound backends.

Work required

1. AsyncShardClaiming trait — mirror of ShardClaiming with async fn claim_next_available(...).
2. async_default_claim_next_available helper — async free function mirroring default_claim_next_available, composing AsyncRunManagement::collect_claim_candidates_into + AsyncCoordinationBackend::acquire_and_restore_into.
3. AsyncCoordinationFacade (optional) — composes AsyncRunManagement + AsyncCoordinationBackend + AsyncShardClaiming with the default claiming implementation.
4. Wire AsyncEtcdCoordinator to implement AsyncShardClaiming using the new default.

References

• PR that introduced AsyncCoordinationBackend + AsyncRunManagement: Break up etcd backend into modular coordinate/run/shard files #148
• Review comment that identified this gap: Break up etcd backend into modular coordinate/run/shard files #148 (comment)
• Requested by: @ahrav