/readyz reports "ready" even when most flush workers have crashed

GET /readyz exists so a load balancer / Kubernetes stops routing traffic to an instance that can't actually process what it accepts. If it reports "ready" as long as even one flush worker out of several is still alive, an instance where 3 of 4 flush workers have crashed keeps receiving 100% of its traffic slice, its ingest queue fills up far faster than the one surviving worker can drain, and every request starts getting 503s — all while the readiness probe keeps insisting everything is fine.

GET /readyz is meant to report whether an instance can actually keep up with what it accepts, but it computes workers_alive using a check that stays true as long as a single flush worker out of several configured ones is still running.

1. pytest practice_tickets/tests/test_ticket_05_readyz_worker_crash.py -v — starts an app with flush_workers=3, cancels 2 of the 3 flush tasks, then calls GET /readyz, which currently still returns 200 ready.

any() and all() are easy to swap when skimming code quickly — both read as reasonable-sounding English, but they encode opposite quantifiers over the same collection. The failure mode this swap produces is especially dangerous because it's silent: nothing crashes, no error is logged, the endpoint just keeps returning 200 while the system is degraded underneath it.

Look at the workers_alive line in app/routers/health.py::readyz. Think about what "every worker is alive" vs. "at least one worker is alive" should each look like as a one-line boolean expression over flush_tasks, and which one this readiness check is supposed to mean.