Readiness dependency graph (converted to project)

This issue has been converted to a project Readiness dependency graph

The Miren coordinator boots by code position. Roughly two dozen components come up in an order maintained by hand in server.go and coordinate.go, with per-component waits bolted on where someone noticed they were needed and a time.Sleep(1s) where they didn't. There's no explicit model of what depends on what, and it's already wrong in places: MIR-1285 is the clearest case, where build saga recovery resumes before the registry and cluster.local name mapping its image push needs, and rolls back.

RFD-88 proposes modeling boot as an explicit dependency graph. Components declare their dependencies, a sequencer brings them up in order and validates at boot (fail-fast, mirroring the saga registry), and named readiness conditions let any consumer wait on the specific state it needs. It's bounded and fail-open, so a wrong or too-strict condition degrades to today's behavior rather than wedging boot, and the same conditions serve at runtime too, as components start getting bounced independently (MIR-904).

This is the companion tracking issue for RFD-88; design and discussion live on the RFD PR. It's also the design home for MIR-661's startup-latency items and MIR-904's ingress split. Rollout is phased: (1) make the graph explicit and validate at boot; (2) gate the fragile consumers (saga recovery, deploy-accept); (3) runtime readiness plus a real health/readiness endpoint, converging with RFD-66.