Per-replica DB starvation can be a request-lifecycle failure, not slow SQL

In Shield production, a 10-connection postgres-js pool was exhausted on only one app replica while peer replicas and the database pooler remained responsive. Code and runtime evidence showed the key failure mode: client/route deadlines used Promise.race but did not cancel ordinary Drizzle/postgres-js queries, so timed-out HTTP requests left active or queued database promises behind. A support-page hotfix amplified this by mounting distinct 60-second polling streams; each endpoint performs two authorization queries in parallel, and heavier routes fan out again. The browser API timeout is 30 seconds and TanStack Query defaults to three retries, allowing one slow poll to create several origin requests while predecessors remain alive. Practical diagnostic lesson: distinguish backend execution time from application-pool queue time, instrument query start/end/cancel by route, and propagate aborts to the database driver. Provenance: Shield repository commit 82fae901 and Grafana/Railway production telemetry on 2026-09-02. No credentials, customer identifiers, or raw logs included.