Worker-connection-gated readiness probe for the coordinator

[cmttt]

Summary

Adds a custom HealthChecker on the coordinator's sync_action gRPC service that returns SERVING only when at least one async worker is connected via the bidi stream. Without this, new coord pods accept discord_api → coord process_action calls before any worker has dialed in, those calls enqueue onto a priority queue with no consumers, and discord_api times out with DEADLINE_EXCEEDED.

Why

Every rolling deploy of osprey-coordinator-asyncio-prd produces ~2,500–3,000 DEADLINE_EXCEEDED errors on discord_api.rpc_client.osprey_coordinator_asyncio.process_action. We've worked through the cluster-config knobs over the last few PRs (surge=1, 30s startupProbe delay, 30s preStop sleep, +grace period) and total failures are roughly unchanged because they all address the drain side. The actual gap is on the warmup side: pigeon's grpc.health.v1 answers SERVING the moment port 80 binds (~2s after container start), well before the bidi service has been announced in etcd and workers have connected. K8s readiness flips green at the 30s startupProbe boundary, traffic flows, and the first ~5–15 seconds of inbound calls have nowhere to go.

How

1. pigeon::Server::with_health_checker — new builder method that pushes a HealthChecker (clone-able closure form: Fn() -> bool + Clone + Send + Sync + 'static) onto every gRPC service registered on the Server. No existing call sites are touched.
2. Connected-worker counter on OspreyCoordinatorServer — Arc<AtomicI64>, owned by the bidi server. Each bidi stream handler increments the counter on entry and decrements it via a WorkerConnectionGuard Drop impl, so disconnects (graceful, panic, cancellation) all release the count without explicit decrement code at every break site.
3. main.rs swap — pigeon::serve(sync_action, ...) is replaced with an explicit pigeon::Server::new(...).with_health_checker(\|\| count > 0).serve() chain, mirroring everything pigeon::serve does plus the new checker. Bidi service still uses the unmodified pigeon::serve (no readiness gating; workers don't K8s-probe it).

Net diff: ~76 lines, 3 files, 0 unsafe code.

Important caveat — companion change required

Pigeon's grpc.health.v1.Health/Check returns SERVING for any request with an empty service name (intentional: that's the liveness fast-path, health.rs:101-104). K8s' built-in gRPC probe defaults to an empty service name, which means just shipping this PR does nothing on its own — the K8s probe still goes through the fast-path and ignores the new checker.

The accompanying discord/discord cluster config must change the readiness probe to:

readinessProbe: healthProbe(
  grpcProbe(80, "osprey.rpc.osprey_coordinator.sync_action.v1.OspreyCoordinatorSyncActionService"),
  {periodSeconds: 5, failureThreshold: 2},
)

Once both ship, the K8s readiness probe will route through the registered service-name path → HealthServer::check → our checker → connected_workers > 0.

Test plan

• cargo check clean (211 pre-existing warnings, no errors / no new warnings from this change)
• Local: spin up coordinator + at least one worker, hit grpcurl localhost:80 grpc.health.v1.Health/Check '{"service":"osprey.rpc.osprey_coordinator.sync_action.v1.OspreyCoordinatorSyncActionService"}' before any worker connects → expect NOT_SERVING; after worker connects → expect SERVING
• Verify connection_guard decrements correctly under panic and cancellation by checking counter after worker disconnects mid-stream
• Once merged + image rebuilt + pinned + companion discord/discord PR shipped: observe a coord rolling deploy and confirm process_action.failure{exception_type:deadline_exceeded} rate during rollout drops materially (target: <100 vs the current ~2,500–3,000 baseline)