fix(ci): pass the App token as softprops/action-gh-release's token input

[noel]

What

bump-version.yml's "Create GitHub Release" step passes the App token via the token input instead of a GITHUB_TOKEN env var.

Why

PR #80 minted a GitHub App installation token specifically so creating the release would fire release: published for release-package.yml, replacing the now-broken classic PAT. But softprops/action-gh-release's token input defaults to ${{ github.token }}, and its own action.yml says: "A non-empty explicit token overrides GITHUB_TOKEN" — so the input always wins over an env var. Setting only env: GITHUB_TOKEN left the action using the default built-in token.

Confirmed on the first real run after #80 merged (v1.0.33):

• The release's author is github-actions[bot], not the App's bot identity.
• release-package.yml has no run matching that release — the release: published event was suppressed, same failure mode chore(ci): mint a GitHub App token for bump-version, drop BOT_TOKEN #80 was meant to fix, just moved one step later.

Verified

• action.yml for softprops/action-gh-release@v3 confirms the token input's precedence over the env var.
• YAML parses.
• Not yet verified end-to-end (needs a real workflow_dispatch run) — the next bump-version run should show the release authored by the App's bot identity and a matching release-package.yml run triggered by the release event.

[github-actions]

Review of PR #82

No issues found.

The PR changes one workflow file, .github/workflows/bump-version.yml. It moves the GitHub App token from the step's env: GITHUB_TOKEN to the token: input of softprops/action-gh-release.

• I did not check the action's source. My understanding is that token defaults to github.token, so INPUT_TOKEN is always populated and would take precedence over an env GITHUB_TOKEN. If so, the old form silently used the default token, and passing the App token as an input is the right fix.
• Nothing else changes. No secrets are exposed, and the job's permissions are the same.
• No Python code, resources, SQL generation or lifecycle behavior is touched, so there are no correctness, security or architecture concerns.

[noel]

Not needed — publishing to PyPI is done manually via workflow_dispatch, so bump-version.yml's release creation doesn't need to trigger anything. Dropping the release: published trigger from release-package.yml instead (separate PR).