[Phase 2] One-action rollback + per-version observability report

[don-petry]

Parent: #495 · Phase 2 · Work type: Feature · Targets SC4, SC8.

Implement one-action rollback (move stable/ring tag back to the prior vX.Y.Z, < 5 min, no caller edits) and a per-version observability report showing each ring/consumer's pinned version (i.e. where each channel tag resolves) and the health metrics gating promotion.

Done when: rollback is a single central tag move; a which-version report shows tag→commit per ring/consumer.

Ref: §5.1, §7 Phase 2.

[github-actions]

Thanks for filing this and linking it back to the parent initiative — the scope is clear and the done criteria are crisp. To help scope the implementation of the one-action rollback: what should that single action look like in practice — a workflow_dispatch trigger in GitHub Actions, a dedicated GitHub UI button, or something else? Knowing the intended interface will shape both the rollback mechanism and how the which-version report surfaces alongside it.

[don-petry]

Decisions / clarifications (from design discussion petry-projects/.github#516)

Channel tags ARE the rollout state

No separate state store. The frontier = the innermost ring not yet on the candidate, derived from where each channel tag resolves. The which-version report this issue calls for is therefore just resolving each <name>/{next,ring0,ring1,stable} tag → commit per reusable.

Rollback mechanics

Rollback = move the ring's channel tag back to the prior vX.Y.Z (single central tag move, < 5 min, no caller edits) — same gated mover identity as promotion (GH_PAT_WORKFLOWS; see #501). A confirmed regression resets the rollout to the beginning (all ring channels roll back to last known-good).

Observability

The evaluate command (4-hourly, read-only — see #501) doubles as the per-version health/observability report: per ring it emits gate state (PROMOTE/SOAKING/INVESTIGATE/RESET), the healthy-run count vs ceil(baseline/7), and failure-rate vs baseline.