Run-control API: project/wave/provider selection + start/stop/pause/resume

[Ryan-Atkinson87]

REST API for run control — the HTTP surface the UI uses to select what to run and to drive the run lifecycle.

Spec: §12 Run control, §4 run model, §6.4 pause/resume.

Acceptance criteria

• Endpoints to select project, wave(s), and provider/plan, and to start/stop and pause/resume a run (§12).
• Start/stop/pause/resume drive the existing engine levers — the wave-loop driver (Wave-loop driver: end-to-end orchestration of the deterministic wave loop #29) and the pause/resume mechanism (Hard pause and two-tier automatic resume (reset-known sleep + backoff probe) #34/Telegram two-way control: inbound command listener and engine dispatch #45) — rather than reimplementing control logic (Principle 1).
• Wave selection reads available waves from GitHub milestone state (authoritative for waves) via the issue/milestone reader (GitHub issue/milestone reader and dependency-order wave assembly #26) — not a hand-maintained list.
• All routes sit behind the single auth dependency (Single-user auth: argon2 password, session cookie, route/SSE guard #6); unauthenticated requests are rejected.
• Validated request/response models (Pydantic); explicit success/failure paths with meaningful errors, no silent pass.
• Contract documented and verified per workflow-api-contract-verification so the frontend (Run-control screen: select project/wave(s)/provider, start/stop/pause/resume #61) consumes a settled shape.
• Tests: each control action dispatches to the right engine lever (engine mocked); auth guard enforced; invalid selections rejected.

Depends on: #29, #2, #6