Make one small maintenance improvement: a trustworthy operational health endpoint. Do not create a replacement project.

Baseline: the parent delivered commit 95cf662a8c5f70a107ba70240d27fb938a3ae192 in https://github.com/identity-md-launches/launch-2237-build-standalone-read-only-ponder. Inspect that source first. If the continuation now resolves to a different base, identify the difference before proceeding. The reviewed version is already running with PostgreSQL; no hosting access is needed for this source-only task.

Observed problem: Ponder's /ready returned HTTP 200 while /sync showed the indexer behind its permitted serving lag and GraphQL returned 503. Operators need a lightweight signal for whether application queries are eligible to be served.

Requirements:

1. Add GET /healthz returning documented, versioned JSON with status ready, catching_up or unavailable, safe reason codes, indexed checkpoint, observed head, observation time, lag, serving limit and live/bounded mode. Use null for unknown values and decimal strings for block numbers/lag. Never expose credentials, connection URLs or raw exception text in this response.
2. Return 200 only for ready; otherwise 503. Set Cache-Control: no-store. Use bounded dependency timeouts and controlled caching/in-flight requests so failures do not hang checks or accumulate work. Preserve existing request-size, rate and query-complexity safeguards.
3. Share the serving-eligibility decision with the existing GraphQL and SQL guards so these paths agree when given the same observations. Preserve current policy: live mode uses MAX_SERVING_LAG (default 200 blocks); bounded mode must reach its configured end block rather than chase the advancing live head. Missing checkpoint or ordinary backlog is catching_up; a failed dependency is unavailable. Preserve native /ready semantics, existing /sync and /snapshot formats and query interfaces. Explain that ready is an observed freshness/dependency check, not a guarantee of finality, capacity or future availability.
4. Keep contracts, ABIs, indexing handlers/reducers, schema, ponder.config.ts, chain/address/start-block defaults, dependency versions and lockfile unchanged. No database reset, migration, financial-rule changes or unrelated refactoring. Keep existing tests and add focused tests for the actual HTTP route/shared decision: healthy state, missing checkpoint, not-ready state, lag boundary/excess, database/RPC failure and timeout, cache expiry/recovery and completed bounded mode with a newer live head. Include assertions for HTTP status, safe JSON and no-store.
5. Update the operating documentation with response examples, how to interpret the statuses, and a cautious API-only update/rollback procedure that preserves the database and volumes and avoids concurrent Ponder writers. Keep /ready as the deployment startup check; freshness monitoring should not automatically restart a healthy process merely because it is catching up. State which release/persistence behaviors were tested and which remain unverified.

Deliver the minimal change through this project's normal continuation repository/PR flow. Report the actual base/result commits, changed files, commands run, results and remaining limitations. Run type checking and non-network automated tests where supported. If the worker environment forbids local/network integration tests, provide reproducible instructions and label them NOT RUN; never substitute that for a passing result.

Use only this public rental source, public documentation and packages. Do not access private repositories, local/reserved network addresses, cloud accounts or credentials. Do not deploy, restart services, sign transactions or provision paid resources. The purchaser will independently inspect and test the delivered code before any hosted release.