Module readiness 

Subsystem readiness tracking (RFC-024 SP4).

A daemon can answer HTTP requests before every subsystem has finished initializing (state store loading, engine provider warm-up, etc.). Naive handling causes 500/Internal errors for the first few hundred milliseconds of every restart, plus hangs when the orchestrator is permanently unavailable. This module gives callers a single atomic gate: a route is “ready” only when both the state store and the engine have reached Ready or Degraded.

Three-state model (per subsystem):

• Warming — startup, not yet Ready. Counts as “not ready”.
• Ready — fully operational. Counts as “ready”.
• Degraded — operational with limitations (e.g. engine initialized but no API key; only a fallback model available). Counts as “ready” so a missing API key does not lock the user out of /api/status for diagnosis.
• Failed — startup aborted (engine init crashed). The state store is still useful for inspection so it is allowed to become Ready independently; the engine Failed state keeps the readiness gate closed and /api/status is the only API that bypasses it (RFC-024 §7.1.1).

Deadline. Callers set a deadline (default 30 s) after which any subsystem still in Warming is force-promoted to Degraded to prevent the gate from staying closed forever.

Structs

ReadinessGate

Readiness gate: tracks two subsystems (state store, engine) and exposes a single is_ready() that returns true when the daemon can safely serve protected API routes.

Enums

SubsystemState

Coarse readiness of a single subsystem.