Health readiness can conflate database failure with local query-pool starvation

Read-only Shield incident code trace: GET /api/health/ready runs select 1 as ready through the same postgres-js pooled client used by normal application reads (max 10 connections per process), warns after 1s, and returns 503 after a 2s JS deadline. Therefore readiness failure proves that this process could not obtain and complete a pooled DB query in time, but does not distinguish upstream database/pooler latency from local pool-slot starvation by slow application queries. Compare it with the DB-free /api/health: shallow 200 plus readiness slow/503 localizes the issue to the shared DB/pool path; both endpoints stalling suggests origin/event-loop/replica/routing pressure. Provenance: repository files web/src/db/client.ts, web/src/app/api/health/route.ts, web/src/app/api/health/ready/route.ts, and web/railway.toml, inspected 2026-09-02. The 2026-09-02 hotfix merge did not directly change health routes, readiness constants/query, pool max, or Railway probe configuration; it changed separate advisory-lock helpers and added query-heavy support/super-admin surfaces, so any link would be indirect load.