Review brief: console release defences

You are reviewing docs/superpowers/specs/2026-10-06-console-release-defences-design.md on branch design-console-release-defences in the carlos/platform repo, at the commit named in the prompt. Read the spec, then read the code it cites:

• internal/release/adopt.go, adoptHost: the restart-failure rollback branch, poisoned, ensureStaged, PointLive, stageBlocked, BakeDir, WithStartUnit.
• internal/host/agent.go: makeRestartRoute, rootRestartRoute, systemctlTryRestartUnit, makeStartRoute, the -stage-only verb and the stage-request relay, the fast converge loop.
• internal/release/release.go: Manifest, Ship.
• cli.go (the direct-bucket ship) and internal/console/apicli.go (the API ship door).
• internal/release/bake.go, internal/release/signer.go, internal/registry/registry.go (Route.Unit, Route.Health, Route.Addr).
• internal/host/alertsink.go.

Fixed rulings (§1): do not re-argue them

Four defences (D1 rollback on a named unit that will not come up, D2 refuse the wrong Go main package, D3 dev-proof requirement for the flagship console, D4 process). No new AWS account. D1 and D2 on everywhere; D3 opt-in per deployment with no per-promote bypass. Enforcement on the adopting box, not the client. External uptime alerting is out of scope. The threat model is mistakes, not a compromised key or bucket.

What to look for

Report mechanisms that fail to honour those rulings or that break something that works today. In particular:

1. Interleavings between the agent's fast loop, the root stage pass, the hourly root pass and the stage-request relay that defeat the refusal record, the proof wait or the settle check. Examples: a relay storm, a bounce loop, a refusal the agent cannot read, a proof minted for a build that is no longer live.
2. States in which D1 makes things worse than today, such as rolling back a healthy build, leaving the unit stopped, or fighting an operator's deliberate stop.
3. Ways today's exact failure still gets through: CLI binary as console, hand ship, promote with the root key.
4. Ways D3 blocks a recovery it should allow (rollback to a previously-run build, break glass) or allows a build it should block (different bytes under a proven version name).
5. Claims about the code that are wrong. Cite file:line.
6. Placeholders, contradictions, or requirements an implementer could read two ways.

A mechanism that is named, bounded and assigned to the plan is complete at spec level; do not pull plan-level detail up into the spec.

Output

Number each finding, give it a severity (P1 breaks a ruling or production, P2 a real defect, P3 clarity), and cite the spec section and any code file:line. End with a one-line verdict: accept, accept with fixes, or reject.