fix(ci): auto-bumped PRs stall because the bot's version-bump push leaves every check in action_required

[ericfitz]

Summary

The per-PR version-bump workflow from #627 works, but its final step pushes the
chore(version): bump to X.Y.Z commit using the default GITHUB_TOKEN, as
github-actions[bot]. GitHub's recursion guard holds every workflow run
triggered by that push at action_required, so every auto-bumped PR is left
BLOCKED until a human clicks "Approve and run" on the pending runs.

This was observed on #627's own PR (#796): after the bump commit landed, all
required checks sat unrun and the PR reported MERGEABLE / BLOCKED with only
the third-party Snyk check reporting. Four runs had to be approved by hand
(gh api -X POST repos/ericfitz/tmi/actions/runs/<id>/approve) before the PR
went green and could be merged.

Now that Version Check is a required status check on the main ruleset
(id 17850702), this affects every PR, not just ones that happen to notice.

Steps to Reproduce

1. Open any PR against main whose branch version does not yet match what the
   PR title implies.
2. Let the "Version Bump" job run; it pushes chore(version): bump to X.Y.Z.
3. Look at the PR's checks on the new head SHA.

Expected Behavior

The push retriggers CI normally and the PR becomes mergeable without human
intervention.

Actual Behavior

$ gh api repos/ericfitz/tmi/actions/runs/32445251601 \
    --jq '{actor: .actor.login, triggering: .triggering_actor.login, conclusion}'
{"actor":"github-actions[bot]","triggering":"github-actions[bot]","conclusion":"action_required"}

All runs on the bumped SHA are completed / action_required; gh pr view
reports MERGEABLE BLOCKED.

Possible Cause

By design, activity performed with the repository's GITHUB_TOKEN does not
trigger new workflow runs, to prevent recursive workflow loops. The runs are
created but held pending approval.

Impact

Every auto-bumped PR needs a manual approval click. The maintainer accepted
this as a temporary state in order to land #627; this issue tracks removing it.

Proposed Fix

Push the bump with a credential that is not GITHUB_TOKEN, so the push
retriggers CI normally. In preference order:

1. GitHub App token (sanctioned pattern) — create a minimal App with
   contents: write, install it on this repo, and mint a token in the job:

   - uses: actions/create-github-app-token@v2
     id: token
     with:
       app-id: ${{ secrets.BUMP_APP_ID }}
       private-key: ${{ secrets.BUMP_APP_KEY }}
   - uses: actions/checkout@v5
     with:
       token: ${{ steps.token.outputs.token }}

2. Fine-grained PAT with contents: write scoped to this repo only, stored
   as a secret and passed to actions/checkout. Less setup, but tied to a
   personal account and needs rotation.

Whichever is chosen, the checkout in the "Version Bump" job must use the new
token (the push inherits the checkout's credentials).

Acceptance Criteria

• A PR whose version needs bumping goes fully green with no manual run approval.
• The credential is scoped to contents: write on this repo only.
• .github/workflows/version-bump.yml documents which credential it uses and why.

Refs #627, #796.

[ericfitz]

Decision (2026-08-23): GitHub App.

Create an App with contents: write, stored as repo secrets BUMP_APP_ID /
BUMP_APP_KEY. Chosen over a fine-grained PAT because it is scoped to the repo,
rotatable independently, and not tied to a user account that expires.

Only the credential creation is manual. Once BUMP_APP_ID/BUMP_APP_KEY exist,
the version-bump.yml change is mechanical: mint an installation token with
actions/create-github-app-token and push the bump commit with it instead of
GITHUB_TOKEN, so the resulting synchronize wave is attributed to the App and
runs without action_required.

Observed again today on #812: the four runs on the bump commit 25727549 all sat
at action_required and needed hand-approval via
gh api -X POST repos/ericfitz/tmi/actions/runs/<id>/approve.