chore(ci): mint a GitHub App token for bump-version, drop BOT_TOKEN

[noel]

What

Replace secrets.BOT_TOKEN (a classic PAT for datacoves-sa) with a short-lived token minted from a GitHub App installation, in the one workflow that used it.

Why

The org now blocks classic PATs, so bump-version.yml fails on the git push --tags step:

remote: Personal access tokens (classic) are forbidden from accessing this repository.
fatal: unable to access 'https://github.com/datacoves/snowcap/': The requested URL returned error: 403

BOT_TOKEN was only needed for one reason: creating the GitHub Release with the default GITHUB_TOKEN would not fire the release: published event, so release-package.yml (which publishes to PyPI) would never run. A token from an external actor (PAT or App installation) avoids that event suppression.

A new GitHub App ("Datacoves snowcap", Contents: read/write, Metadata: read-only, installed only on this repo) replaces the PAT. actions/create-github-app-token mints a ~1 hour installation token at the start of the job from the APP_ID/APP_PRIVATE_KEY secrets, used for both the version-bump push and the release creation.

Verified

• YAML parses (python3 -c "import yaml; yaml.safe_load(...)").
• APP_ID / APP_PRIVATE_KEY secrets exist on the repo.
• FragileTech/bump-version's login input is only used as the HTTPS basic-auth username (https://<login>:<token>@github.com/...), confirmed by reading its action.yml — x-access-token is GitHub's documented convention for authenticating with an App installation token over HTTPS, in place of the old datacoves-sa login.
• The actual workflow_dispatch run (which needs APP_ID/APP_PRIVATE_KEY in Actions) hasn't been exercised yet — worth a manual dispatch run after merge to confirm end-to-end before deleting BOT_TOKEN.

Follow-up

Once a real run succeeds, delete the now-unused BOT_TOKEN secret.

[github-actions]

Review of PR #80

Scope: this PR only changes .github/workflows/bump-version.yml. It swaps BOT_TOKEN for a GitHub App installation token. No snowcap resource, SQL or lifecycle code is touched.

No blocking issues found. Two things worth checking before merge:

• .github/workflows/bump-version.yml:17-22: the App token is minted without explicit permission-* inputs, so it gets every permission the installation has. The workflow only needs contents: write to push the bump commit and create the release. Adding permission-contents: write would limit the token to that. This is optional hardening.
• .github/workflows/bump-version.yml:33: login: x-access-token is the standard username for token pushes, so that is fine. If main has branch protection, the App must be in the bypass list, otherwise the push will fail. The old datacoves-sa PAT was presumably already allowed. Confirm APP_ID and APP_PRIVATE_KEY are set as repo secrets.

The action is pinned to a commit SHA, which is good. The diff includes no credential literals.