ci: every release-please PR's checks are held as action_required, so no release merges unattended

[forkwright]

Finding

Every workflow run on the release-please--branches--main branch is created with conclusion
action_required and never starts. Branch protection requires cargo audit, cargo deny, and
gate / gate, so the release PR sits BLOCKED with zero checks — not pending ones, absent ones
— until a human approves the runs by hand. That is one manual intervention per release, forever, and
it is invisible: a release PR blocked on held runs looks exactly like one blocked on slow runs.

Evidence

gh run list --repo forkwright/akroasis immediately after release-please updated #430 to head
304754d6:

completed  action_required  release-please--branches--main  Gate Attestation
completed  action_required  release-please--branches--main  Dependabot Auto-Merge
completed  action_required  release-please--branches--main  Security

The same command shows the contrast on an ordinary branch in the same repo — fix/231-vault-error-fidelity
returned success for Gate Attestation and Security with no approval step. So this is not a
repository-wide approval requirement; it is specific to the branch whose commits are authored by
github-actions[bot].

gh api repos/forkwright/akroasis/branches/main/protection gives the required contexts:

required checks: ['cargo audit', 'cargo deny', 'gate / gate']
strict(up-to-date): False

.github/workflows/release-please.yml:23 runs googleapis/release-please-action@45996ed1 # v5.0.0
with no token: input, so it authenticates as the default GITHUB_TOKEN.

Held runs on #430 were approved manually (32455351809, 32455351049, 32455351039) to unblock
v0.4.2. #427, #423, #416 and every earlier release merged, so this has been absorbed by hand each
time rather than noticed as a standing defect.

Why this matters

The release path is the one path that must work without a human at the keyboard, and it currently
cannot. Worse, the failure is silent and mimics a benign state: mergeStateStatus reads BLOCKED
and statusCheckRollup is empty, which is the same shape as a release PR whose checks have not been
scheduled yet. A seat polling for green has no way to tell "waiting" from "will wait forever" without
querying the run list separately, which is not part of any normal merge check.

It also interacts badly with the release policy: agents cut minor and patch releases, so the seat
expected to complete a release is the one that cannot, without reaching for a repository-admin
action.

Desired correction

Give release-please a credential whose pushes are not subject to the bot-approval gate — a
fine-grained PAT or a GitHub App installation token in secrets, passed as the action's token:
input. That is the upstream-documented remedy and it also fixes the related recursion caveat, where
GITHUB_TOKEN-authored events do not trigger downstream workflows at all.

This needs an operator action: provisioning the credential is outside an agent seat's authority.
Two things are worth deciding together — whether a PAT or an App is preferred fleet-wide, since every
repo running release-please has this same defect, and whether the token should be scoped per repo or
shared.

Until then the interim is mcp__kanon__ci_hold_sweep (or approving the current head's runs by hand,
after checking they belong to the current head — approving an older generation cancels the newest).

Done when: a release-please PR opened with no human present reaches a green required-check set on
its own, and the manual approval step is gone from the release path.

[forkwright]

Operator decision: a GitHub App installation, org-wide.

Chosen over a per-repo fine-grained PAT for the reasons that made this fleet-shaped rather than
repo-shaped: an App is not tied to a personal account, does not expire on a schedule, scopes per
repository from one installation, and fixes every repo running release-please at once instead of
eight secrets with eight expiry dates.

Provisioning is operator-owned, so this issue stays open on that. What is needed:

1. A GitHub App on the forkwright org with Contents: read/write and Pull requests:
   read/write, installed on the repos running release-please.
2. Its App ID and private key in repository or org secrets.
3. A token-minting step in .github/workflows/release-please.yml feeding the action's token: input,
   in place of the default GITHUB_TOKEN.

Step 3 is mine once the credential exists, and it is small — one step plus one input.

Measured cost of not having it, from tonight alone: four manual approval cycles, on releases
v0.4.2, v0.4.3, v0.4.4 and v0.6.0. Each is three actions/runs/<id>/approve calls against the
current head, and approving an older generation cancels the newest, so it is not safely scriptable
by a seat that has not checked which head it is looking at.

Worth carrying to whoever provisions it: the same App fixes the second half of this defect, which the
body does not spell out. Events authenticated by the default GITHUB_TOKEN do not trigger downstream
workflows at all — so beyond the held runs, a release-please push cannot start anything that keys on
push. An App token is a real actor and does.

[forkwright]

Fresh measurement of how often this recurs, from a single session this morning.

PR #458 (release 0.6.1) needed its held runs approved twice in ~40 minutes:

• 10:47 — ci_hold_sweep approved 3 held runs (32473792741, 32473792831,
  32473792094). PR reached all-checks-green.
• 11:24 — PR fix(kerykeion): surface AES init failures during trial decryption #459 merged, release-please regenerated chore(main): release 0.6.1 #458, force-pushing a new
  head. Every check on the new head was held again; statusCheckRollup came
  back empty while mergeStateStatus stayed BLOCKED. A second sweep
  approved 3 more (32500051707, 32500052281, 32500052306).

Two properties of that make it worse than the run count suggests:

The blocked state is indistinguishable from a slow gate. An empty rollup plus
BLOCKED looks exactly like checks that have not started yet. Nothing reports
"these are waiting on a human"; the only way to tell is to query the runs' held
status directly. A session that assumes CI is merely slow waits forever.

It re-arms on every regeneration, not once per PR. Any merge into main
causes release-please to rewrite its PR, which produces a new head, which holds
the checks again. So the cost is not one approval per release PR but one per
merge that lands while a release PR is open — precisely when throughput matters
most.

skipped_superseded was 80 on both sweeps, so the backlog of held historical
runs is real but correctly bounded away from open-PR heads by the tool.

This does not change the chosen direction (a GitHub App, org-wide) — it
quantifies what the interim costs while that is unprovisioned, and the trigger
condition to test any fix against: approve, then merge something else into
main, and confirm the regenerated head's checks start on their own.