[belikh]

A harness that launches iris has no way to tell "the monitor is not listening yet" from "the guest started and failed before the kernel came up", and machine-start sent into the gap is silently lost. This makes the lifecycle explicit and queryable.

• machine-start is idempotent and prints its transition (idle -> starting -> running, or running (no change)); machine-stop acknowledges symmetrically. The state is derived from the CPU's own running flag where it matters, so a breakpoint or execution-control command cannot leave a stale copy behind.
• machine-status [json] reports state (idle/starting/running/halted), cpu_running, monitor_ready and the bound monitor address.
• The CI socket gains the same status command (one source of truth with the monitor), and iris-ci status [--wait-ready SECS] [--json] polls it instead of sleeping.
• In --ci the control socket is now created after Machine::start has bound the monitor, so a successful connection is itself a readiness signal. The CPU still stays parked, so restore-before-boot keeps working.
• Tests: command before ready, duplicate start, start after stop/reset, invalid transitions, plus a process-level --ci test proving the poll path.

debug.md documents the new command and STORAGE.md documents the CI readiness poll.

Tests on upstream/main: cargo test --workspace (1179 passed, 0 failed) and cargo test --workspace --features jitv2 (14 suites, 0 failed).

[techomancer]

bleh, looks like we need this conflict to be resolved ;(

[techomancer]

superseded by #312