[OPS-1301] Use baton-ci app token in capabilities.yaml

[ennyjfrick]

Replace the long-lived RELENG_GITHUB_TOKEN PAT with a short-lived baton-ci app token scoped to the current repo.

Mirrors the OPS-1300 templated workflow pattern. With the Connector Rules ruleset hardened, the legacy PAT only continues to work because of the temp org-admin mitigation; this PR replaces it with the proper App-token bypass actor before that mitigation is removed.

Linear: OPS-1301

🤖 Generated with Claude Code

[linear]

OPS-1301 Replace RELENG_GITHUB_TOKEN in legacy untemplated capabilities workflows

[github-actions]

Claude finished @ennyjfrick's task in 1m 33s —— View job

---

PR Review: [OPS-1301] Use baton-ci app token in capabilities.yaml

• Gather context and read changed files
• Review the diff against origin/main
• Post review findings

---

Overall: Looks good. The token-minting step is correctly structured and placed before checkout. One potential issue worth considering below.

What's changed

The PR adds an actions/create-github-app-token@v2 step to mint a short-lived baton-ci app token, scoped to the current repo, and uses it in place of the long-lived RELENG_GITHUB_TOKEN PAT for the checkout step.

Review

Token minting step (lines 15–22) — Correct. The app token is properly scoped:

• owner → github.repository_owner
• repositories → github.event.repository.name (single-repo scope)
• Placed before checkout so the token is available when needed.

Checkout step (lines 24–27) — Correct. Uses steps.ci-token.outputs.token instead of the old PAT.

Potential issue: EndBug/add-and-commit push token

The Commit changes step (lines 48–53) uses EndBug/add-and-commit@v9, which has a github_token input that defaults to ${{ github.token }}. Depending on the action version's behavior, it may override the checkout-persisted credentials with the default GITHUB_TOKEN when pushing.

If the Connector Rules ruleset blocks pushes from GITHUB_TOKEN once the org-admin mitigation is removed, the commit/push step could fail even though checkout succeeds. Consider explicitly passing the baton-ci token:

- name: Commit changes
  uses: EndBug/add-and-commit@v9
  with:
    default_author: github_actions
    message: 'Updating baton capabilities.'
    add: 'baton_capabilities.json'
    github_token: ${{ steps.ci-token.outputs.token }}

This may already be handled by actions/checkout's persisted credentials — but explicitly passing it removes the ambiguity and future-proofs the step. Fix this →

Other notes

• release.yaml still references RELENG_GITHUB_TOKEN but that file is managed by baton-admin (line 1: # This file is managed by baton-admin. Do not edit directly.), so it's correctly out of scope for this PR.
• No other workflows reference RELENG_GITHUB_TOKEN besides release.yaml.