fix(tag-release): use GitHub App token to restore release.yml trigger

[j7an]

Summary

Closes #14. Replaces the default GITHUB_TOKEN used by tag-release.yml with a short-lived GitHub App installation token, so tag-push events propagate and release.yml (which is on: push: tags) fires as intended.

The reactive model in release.yml is preserved — it still runs on any tag push, including CLI pushes from a developer machine. Only the pusher identity in the upstream workflow changes.

Changes

• .github/workflows/tag-release.yml:
  • Preflight step — fails fast with a README-linked error if vars.RELEASE_BOT_APP_ID is empty. Runs before any side effects.
  • Mint step — actions/create-github-app-token@1b10c78c7865c340bc4f6099eb2f838309f1e8c3 # v3.1.1, SHA-pinned to match the existing convention.
  • Checkout — now takes token: \${{ steps.app-token.outputs.token }}, which persists the App token as the push credential in .git/config. The subsequent git push step body is unchanged.
  • Compute-release logic unchanged.
• README.md — new ## Release Bot App setup section documenting required config (vars.RELEASE_BOT_APP_ID, secrets.RELEASE_BOT_PRIVATE_KEY), one-time provisioning steps, verification, and rotation. The preflight error message links to this section's auto-anchor.

How it works

GitHub's documented recursion guard prevents events caused by `GITHUB_TOKEN` from creating new workflow runs. That's why `release.yml` has been dormant since it was introduced. Switching the pusher to a GitHub App installation token bypasses the guard — App-triggered events propagate normally.

The CLI escape hatch (`git push origin v1.4.0` from a developer laptop) continues to work for free: laptop credentials were never `GITHUB_TOKEN` in the first place.

Test plan

• `actionlint` clean on `tag-release.yml`
• Zizmor workflow passes in CI
• Post-merge positive E2E: dispatch Tag Release with `bump=patch`, confirm `release.yml` fires within ~30s, `gh release view` succeeds, and `git ls-remote origin v1 v1.3` both point at the new patch.
• Post-merge CLI regression: push a disposable tag `v1.99.0-test` from the CLI, confirm `release.yml` fires normally, delete the test tag and release afterward.

Prereqs already in place

• `vars.RELEASE_BOT_APP_ID` set to the App ID.
• `secrets.RELEASE_BOT_PRIVATE_KEY` set to the App's PEM private key.
• The App is installed on this repo with `Contents: Read and write` and no other permissions.

Notes for reviewers

• The preflight step writes a markdown link in `$GITHUB_STEP_SUMMARY` using a relative path (`../../README.md#release-bot-app-setup`). Relative links may not render as clickable in the Actions step-summary UI, but the `::error::` annotation text (`see README#release-bot-app-setup`) is self-describing — polish item, not a correctness bug.
• Job-level `permissions: contents: write` is retained intentionally. It's orthogonal to the App token and governs any future step that uses `GITHUB_TOKEN`; removing it is out of scope for this fix.