S22: read-only Mission view on the coordination page (SHIP_MISSION_VIEW, default off)

[im-tyler]

Changes

• New src/mission-view.ts: derived projection of a coordination record onto mission.ts (api -> client nodes, inputRevisions.api = merge anchor, Deliverable.revision = delivery record merge sha, failed-API hold = blocked, accept-risk = waiver, integrationGate as an aggregate gate). Acceptance comes ONLY from the task record (acceptance === "accepted"); merged/confirmed-but-undecided is completed.
• web/src/routes/coordination.tsx: read-only "Mission view" panel (ready, blocked, stale, aggregate acceptance, integration), rendered only when SHIP_MISSION_VIEW=on. Off: no extra loader key, nothing rendered.
• Shadow only: no launching, no persistence, coordination.ts untouched (launchNext idempotency unchanged).

Checks

• lint clean; root dist/**/*.test.js 2006 pass / 0 fail (1983 + 23 new); web 165 pass; web build OK.
• grader-sensitivity / pj-b-deploy-recovery NOT run (fixed port 8901 contention); CI runs them.
• 23 new tests: recorded fixtures (fresh, api running, failed-API hold, retry clears block, stale revision, merge without sha, waivers, integration gate), real store path (facts from event logs + delivery records), launchNext on failed-API unchanged.
• Negative controls (mutated, watched fail, restored): finished-counts-as-accepted (5 fail), integration gate ignored (1), planned-on always current / no stale (2), compatibility always covered (3).

Not verified / still open

• Default-off page byte-identity is by construction (no key, no element); no render test of the route.
• The coordination record stores one anchor; a merged client's own anchorSha is overwritten, so planned-on is api.anchorSha unless supplied. Staleness is detected against the delivery record's sha.
• Not checked against a live system.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VqsBNqvaWezf1DwQrAnVgX

---

Generated by Claude Code