Cockpit: release board — milestone-centric default view (burn-up, needs-you, in-flight, up-next, blocked, linked PRs)

[robercano]

Blocked by #206

Context

The cockpit shows flat sections (issues by module, PRs, workers) that the owner cross-references by hand. But the loop's actual unit of work is the release milestone: #174 made the census milestone-scoped and #176 made the milestone the release unit, gated by a Release vX.Y.Z issue's blocking edges. "What is the loop doing for this release, what's next, what's stuck, what needs me" should be the first thing the cockpit answers — as its default view.

Proposal

On the SPA (from #206's /api/state), a milestone-centric board as the landing view:

1. Release header: active milestone title, burn-up (closed/total), the release-gate issue and how many blockers it still has, link out to GitHub.
2. Groupings derived from the same signals the census uses — computed SERVER-SIDE into the state JSON (the SPA only renders), so grouping/ordering is fixture-testable in cockpit.test.sh and cannot drift from loop-census.sh semantics:
   • Needs you — needs-human-labeled issues/PRs + PRs awaiting first/re-review (today's strip, scoped to the board).
   • In flight — live worker rows with phase and the age/timeout-budget badge (issue Cockpit: surface driver age/timeout budget on live-progress rows #116's).
   • Up next — open, unblocked, planned issues in ADVANCE order (priority:* labels, then age).
   • Blocked — with which open blockers, each clickable.
   • Done — closed issues in the milestone.
3. Issue cards: number/title, priority chip, labels, blocking in/out degree, and associated PRs with review + CI state (linked via the feat/issue-N-* branch convention and closing keywords).
4. Milestone picker for the other open milestones, plus a feedback-inbox strip for unmilestoned feedback issues (mirrors roadmap.sh's section).

Acceptance criteria

• The SPA's default view is the active-milestone board with the five groupings; for a given fixtures dir, membership and up-next ordering match what the census would compute.
• Issue cards show their linked PRs with review + CI state.
• Grouping/ordering lives in the state JSON (server-derived) and is covered by fixture tests — including a milestone with no live workers (renders an idle board, not an error) and an issue with multiple PRs.
• Milestone picker switches boards entirely client-side from the same state document (no extra round-trips).

Notes

• The interactive dependency graph (sibling issue in this milestone) embeds in/next to this board — keep the card model and status classification shared between them (one source of truth in the state JSON).