Design check: split gateway liveness and readiness probes?

[er-s-an]

Problem / motivation

The gateway's current /health endpoint is intentionally a minimal liveness check: it returns {"status": "ok"} whenever the health listener is serving. The health server starts alongside the agent loop and channels, so an orchestrator cannot distinguish "the process is alive" from "the runtime is ready to accept work" during startup, dependency recovery, or graceful shutdown.

The existing endpoint was introduced in #2625 and its exposure was hardened in #4906. I searched issues, PRs, and Discussions but did not find a separate readiness contract.

Proposed contract (ASK-FIRST)

Before implementing anything, would the maintainers be open to a narrow change that:

• keeps GET /health unchanged as the backwards-compatible liveness probe;
• adds GET /ready;
• returns 503 while the core runtime is still initializing, is shutting down, or cannot accept work;
• returns 200 only after the required runtime components are available;
• exposes only bounded component names/states, with no configuration values, paths, credentials, or provider details.

Semantics that need maintainer direction

1. What should gate readiness: the agent loop and MCP initialization only, or cron and all enabled channels as well?
2. Should an unavailable optional MCP server/channel make the gateway unready, or be reported as degraded while readiness stays green?
3. Would you prefer a simple {"status": "ready"} response, or a small component summary suitable for operators?

If this direction fits the project, I can prepare a narrowly scoped PR with startup, degraded-state, shutdown, response-disclosure, and backward-compatibility tests.