Re-validate generation 15 through the canary/ring gates the emergency finalize bypassed

[willgriffin]

Summary

#69 advanced stable to generation 15 under explicit incident authorization,
deliberately bypassing the canary/ring evidence gates. The bypass was justified —
the runner pool was the system being recovered — but the validation debt it
created has no tracking issue. The entire fleet is currently pinned to an
artifact that has never passed the promotion gates.

The condition that forced the bypass is gone: brokered Patdown JIT runners are
serving production jobs again (happyvertical/have-config run
30296461297
ran on patdown-jit-a220f0c37d36e1d585c2a7c3-runner, group
brokered-general-linux-x64). The gates can now be run.

What was skipped

From #69 (merged 2026-07-27T14:07Z):

Advances the default stable authority pointer directly from generation 13 to
generation 15. … Collapses prepare/promote/finalize because the current runner
pool is the system being recovered; ring evidence is intentionally bypassed
under explicit incident authorization.

It also closed #68, the normal prepare generation 15 transition, so the
ordinary prepare → canary → promote → finalize path never ran for this generation.

Evidence of the gap

.github/agent-policy-channels.json, current:

"transition": { "action": "finalize", "from_revision": 11, "to_revision": 12,
                "evidence_sha256": null }

Contrast the revision-11 abort (#65), which carried both digests:

Evidence SHA-256:      49c6cd003b9b9ccb7f2bbaf87d0e94eb8cbfbc5eb0566ec18baf898d1f7f2947
Signed bundle SHA-256: 5bf12e446105dfc88ee43259e9fdab04885308fc366aec9f5198d57c781e886b

A null evidence digest on the transition that put the current stable artifact
in place is the whole issue in one field.

Why it matters

Generation 15 is what every consumer's lifecycle check runs today —
happyvertical/have-config, sdk, smrt, pdf, ocr, and this repository. It
was published from a verified protected-main build and the structural validators
passed, so there is no reason to suspect it is bad. But "we have not found a
problem" is not the same as "it passed the gates", and the gates are what the
promotion contract actually requires.

What to do

1. Dispatch the canary for both public targets — arc-happyvertical and
   arc-anytown — against the generation-15 artifact
   ghcr.io/happyvertical/agent-policy@sha256:0a00ee64…65a2fb, and capture the
   correlated verify-cleanup pair for each.
2. Record signed evidence for the result.
3. Reconcile the channel state: either backfill evidence_sha256 on revision 12,
   or carry the evidence forward explicitly on the next transition so the audit
   trail shows generation 15 was validated after the fact rather than never.
   Whichever is chosen, it should be a deliberate, recorded decision — the
   current state reads as an unvalidated promotion.
4. If the canary surfaces a genuine failure, treat it as an incident follow-up
   and roll forward to a validated generation rather than editing evidence.

Acceptance

• A correlated canary + cleanup evidence pair exists for generation 15 on both
  public targets.
• The channel record for generation 15 no longer carries a bare null evidence
  digest with no explanation.
• The next ordinary transition runs the unmodified prepare → canary → promote →
  finalize path.

Follow-up to #69; supersedes the validation that #68 would have carried.