ci(release): authenticate release-please via a GitHub App

[igorlg]

Why

When we shipped v1.2.0 (the Lambda Layer feature release), the release-please PR's required status checks all sat at "Expected — Waiting for status to be reported" because GitHub deliberately blocks the default GITHUB_TOKEN from triggering downstream workflow runs (anti-recursion). The maintainer had to push an empty commit to the release-please branch from a real account before any check could run. That works once but it's not a sustainable release process.

What changes

Workflow — .github/workflows/release.yml:

- name: Mint App installation token
  id: app-token
  uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
  with:
    app-id: ${{ vars.RELEASE_PLEASE_APP_ID }}
    private-key: ${{ secrets.RELEASE_PLEASE_PRIVATE_KEY }}

- uses: googleapis/release-please-action@5c625bfb5d1ff62eadeeb3772007f7f66fdcf071 # v4
  id: release
  with:
    config-file: release-please-config.json
    manifest-file: .release-please-manifest.json
    token: ${{ steps.app-token.outputs.token }}    # <-- new

Repo state (one-time UI work already done by the maintainer):

• vars.RELEASE_PLEASE_APP_ID — App's numeric ID, non-sensitive
• secrets.RELEASE_PLEASE_PRIVATE_KEY — PEM private key, sensitive
• GitHub App igorlg-release-bot: owned by igorlg, installed only on igorlg/cfn-handler, granted exactly Contents: write + Pull requests: write

Docs — docs/CI.md:

• Replaces the obsolete "enforce_admins trade-off" note with a new "How release-please PRs trigger required checks" section
• Updates the v1.0.0 postmortem reference to point at the new section

Why App over PAT

A fine-grained PAT works equivalently but expires annually → manual rotation chore. The App's private key has no GitHub-imposed expiry; only short-lived per-run installation tokens appear in workflow run contexts. After the ~10-minute one-time UI setup, ongoing maintenance is zero.

Verification

• just openspec-validate — change validates strictly against the existing ci-infrastructure baseline
• just lint — ruff + cfn-lint clean
• just ci-check — all 103 tests pass; coverage 99.48%
• actions/create-github-app-token@bcd2ba49 is the SHA for v3.2.0 (released 2026-05-12); secure-workflows.yml policy satisfied (SHA + # vX.Y.Z comment)

How this gets validated end-to-end

This PR's merge does NOT itself trigger a release (no feat: / fix: since v1.2.0 shipped). The next feat: / fix: merge will be the first release using the new App. At that point we expect:

• Mint App installation token step succeeds
• release-please bot opens a release PR
• All required checks fire automatically on the release PR (no manual unblock)
• Squash-merging the release PR triggers the full downstream pipeline

If the App credentials are missing/invalid, the mint step fails loudly before release-please-action runs; we don't silently fall back to GITHUB_TOKEN.

OpenSpec

• Change ID: ci-release-please-app-auth
• Modifies the existing "Release pipeline driven by Conventional Commits and Trusted Publishing" requirement in the ci-infrastructure capability
• Two new scenarios: (a) release PR triggers required checks; (b) missing/invalid App credential fails loudly
• Will archive after this PR merges + first post-merge release-please PR appears with checks running