Is a builder holding an issue right now -- unauthenticated, like /api/health itself, because the one caller that needs this from outside the process has no bearer token to send.

WHY THIS EXISTS. scripts/promote-to-production.sh redeploys rooster -- the Railway container running tools/rooster_worker/drain.py's hands loop -- on every promotion, with nothing asking first whether a build is still checked out inside it. drain.py's own ROOSTER_DEPLOY_DEBT_CEILING already refuses to deploy THROUGH a build it drives itself (its own comment: "SO ROOSTER'S OWN DEPLOY WAITS FOR THE FLOOR TO BE EMPTY... Drain then deploy -- never deploy through a build"), but that guard runs INSIDE the container and has no way to answer a question asked from outside it -- a shell script on a different machine cannot read another process's memory (drain.HeldClaims). This is that question, asked of the database both sides already agree on.

issues_service.builds_in_flight is the exact database mirror of what HeldClaims tracks in-process, so the answer here and the answer drain.py would give itself are the same fact read from two places, never two different guesses at it.

THE CEILING RIDES ALONG rather than being copied into the shell script as a second literal -- ROOSTER_DEPLOY_DEBT_CEILING is the one place that number is decided (this repo's own "one fact, many literals drift" rule), so a caller that needs it reads it off this response instead of hardcoding it a second time somewhere that could drift out of step.

⛔ITS OWN CONNECTION, NEVER THE REQUEST POOL (ISS-1565). Its one statement takes 4 ms, but the route measured p95 13 s, max 38 s, with 1,328 ms of pool wait per request: it queued behind every other request for one of the pool's few slots. A short-lived connection with a connect and statement limit answers in milliseconds or fails fast, the same shape /api/health's own reads use. A failure is a 503, never a guessed in_flight: a stale "0" would let a promotion deploy through a build.