ci: adopt the fleet release-PR healer

[forkwright]

Finding

Release PRs in this repo arrive with their required contexts absent rather than red.
release-please creates its PR with GITHUB_TOKEN, and GitHub raises no workflow-triggering
events for that token, so branch protection holds a PR with a missing context forever — nothing to
re-run, nothing to approve.

Evidence

Measured across the fleet 2026-08-26: four release PRs (akroasis#465, epistole#127, harmonia#733,
gnomon#68) sat 8 days at mergeStateStatus: BLOCKED with an empty statusCheckRollup
while their workflow runs waited at action_required.

aletheia has carried the only healer for months. A file-existence check found
release-pr-checks.yml 404 in all 17 other release-please repos, and nothing visible from
inside any of them revealed the gap.

Why this matters

A missing check is worse than a failing one. A red check advertises itself; an absent one looks
exactly like a PR that has not finished. Releases stop, and the only symptom is a PR that appears
to be waiting on CI.

Desired correction

Adopt the reusable healer (forkwright/.github#56). This file asks for it and declares nothing
about how it works, so it cannot drift from the other adopters.

Done when: a subsequent release PR here reaches a non-empty statusCheckRollup without a human
approving runs by hand.

The permissions block is load-bearing

Not the usual boilerplate. For workflow_call the caller's permissions is a cap — a called
workflow can only downgrade the token, never upgrade it. A caller declaring the customary
contents: read alone would leave the healer unable to approve a single run, and the only symptom
would be a release that stayed stuck.

Proven, not assumed

The whole path was exercised on akroasis before this rollout:

• Actions: write confirmed present in the reusable's job token, so the caller's grant does reach
  it (run 32982564877).
• GITHUB_REPOSITORY resolves to the caller — the healer reported #465 at b75af1a6f,
  akroasis's own release PR, while running from forkwright/.github.
• The workflow_run trigger fired automatically on release-please completion and superseded a
  manual dispatch via cancel-in-progress, exactly as designed.
• GITHUB_TOKEN + actions: write approving a genuinely held run: 201, and the run moved
  action_required → in_progress (probed on zetesis run 31286567826). No PAT and no repo
  secret are required — an assertion to the contrary lived unexamined in aletheia's copy for
  months and is false.