process pool: depends_on for ordered startup, with readiness semantics

Came up while planning the optative-process-pool extraction.

Real supervisors (systemd, docker-compose, etc.) let you declare process dependencies so things start in the right order. A `depends_on: Vec` field on `ProcessSource` is the obvious shape. The implementation is where it gets interesting.

The naive "topo-sort the desired set, call reconcile in waves" approach has a subtle flaw: `Lifecycle::enter` is synchronous and returns as soon as `Command::spawn` does, which means the OS has fork+exec'd but the child may not be *ready* (still initializing, opening sockets, loading config). Topological order of enter calls is not the same as readiness ordering. For most real use cases, the dependent process actually needs its dep to be *operational*, not just "started".

This pushes the design toward something richer than a single bool per process: a per-process readiness signal (stdout line, port open, heartbeat, user-provided predicate) plus a way for the pool to gate enter of dependents until those signals fire. A nested reconciler with nested per-process state is one plausible shape (each process has its own internal "readiness reconciler" and the outer pool waits for sub-states to converge before launching dependents).

Flagging as a real design item rather than something to land quickly.

Drafted by Claude (AI assistant) during a design review.