Repair the health-check problems below in delivered commit 7631f26753845dd5bd8254f5099fe8d042bff3df, keeping the rest of this maintenance change. This is the same public repository: https://github.com/identity-md-launches/launch-2237-build-standalone-read-only-ponder. Source delivery only; no deployment or access to private infrastructure.

Independent review passed the Docker build, typecheck, all 28 unit tests and the supplied integration suite using PostgreSQL 17.7 and disposable Anvil. Additional tests of the actual API module, with controlled dependencies, found these defects:

1. A late result can reinstate stale readiness after timeout. shared/health.ts:createBoundedCache caches a loader result at its completion time even if the operation previously timed out. src/api/index.ts collects the database, head and readiness with Promise.all. Reproduction: HEALTH_TIMEOUT_MS=100, HEALTH_CACHE_MS=100, checkpoint 900, head 1000, MAX_SERVING_LAG=200, native readiness 200. Delay only the checkpoint read for 600 ms; head responds immediately. The first health request times out. Advance head to 1600 while the read is delayed. When the old operation finally completes, /healthz returns 200 ready with lag 100 and an observation over 600 ms old, despite a 100 ms cache limit. GraphQL/SQL guards also permit that sample. A fresh probe then correctly reports lag 700 and rejects queries. Do not turn expired/timed-out observations into fresh successful eligibility just because a slow dependency finally settles. Bound observation age and require a fresh completed sample after timeout, while keeping at most one active probe and preventing unbounded retry/work accumulation. Retain recovery once dependencies respond normally.

2. The timeout diagnosis is fabricated. failureSample marks every dependency as timed out and sets observedAt to now. A slow RPC with an immediately healthy database/native readiness therefore returns reason database_timeout. Use accurate per-dependency outcomes, or an honest generic probe-timeout reason when attribution is unknown. Do not invent a successful observation timestamp or erase known distinctions. /sync should remain interpretable and its existing response shape preserved.

3. nativeReadiness maps every non-2xx response to not_ready. A native /ready HTTP 500 therefore appears as ordinary catching_up. Distinguish the documented startup/backfill response (503) from unexpected failures such as HTTP 500/404; unexpected failure must produce unavailable with a safe reason.

Add regression tests against the actual health route and production probe orchestration, including the above delayed-completion/head-advance case and GraphQL/SQL eligibility, RPC-only timeout, database-only timeout, native HTTP 500 versus 503, and recovery. Use controlled dependencies/time where possible. Keep all existing tests. The current tests only supply prebuilt decisions to the health handler, so they missed these wiring failures.

Also correct the rollback instructions: the previous deployed release 95cf662 does not have /healthz, so rollback validation must use its supported /ready, /sync and an actual query. State plainly that the existing source fingerprint gives this API update a new physical schema/backfill; retain both schemas and avoid overlapping writers. Do not alter fingerprinting or introduce a schema migration to disguise this behavior.

Keep contracts, ABIs, indexing logic, financial rules, schema/configuration defaults, dependency versions and lockfile unchanged. Preserve query interfaces and existing safeguards. Use safe reason codes without raw errors or credentials. Report exact changes, commands/results and remaining limitations honestly; mark unavailable integration checks NOT RUN. Only public rental source, documentation and packages; no private files, credentials, cloud access, paid provisioning, signing or public-chain transactions. We will independently review and test before releasing.