Migrate versioning workflow from PAT to GitHub App token

[anth-volk]

Fixes #638

Summary

• Replaced expired PAT (POLICYENGINE_GITHUB) with a GitHub App token in the versioning workflow
• Uses actions/create-github-app-token@v1 with APP_ID and APP_PRIVATE_KEY secrets (already configured in the repo)
• Matches the pattern used in policyengine-api-v2-alpha

Test plan

• Merge a PR with a changelog fragment and verify the versioning workflow successfully pushes the "Update package version" commit
• Verify that commit triggers code_changes.yaml and the PyPI publish step runs

🤖 Generated with Claude Code

[baogorek]

Claude aggressively posted this comment on my behalf:

One thing I initially flagged: the `EndBug/add-and-commit@v9` step doesn't explicitly receive the app token — so I worried it might fall back to the default `GITHUB_TOKEN` for the push, which wouldn't trigger downstream workflows (like PyPI publish via `code_changes.yaml`).

After digging in, this is not a concern. Here's why:

- `actions/checkout@v4` with `token: <app-token>` persists that token into the local git config via an `http.extraheader` credential (this is the default `persist-credentials: true` behavior).
- `EndBug/add-and-commit@v9` just shells out to `git push` — it uses whatever credentials the local repo already has configured. Its `github_token` input is only used for GitHub API calls (fetching user info for commit metadata), not for git operations.
- Their README confirms: *"When pushing, the action uses the token that the local git repository has been configured with."*

So the version-bump commit will be pushed with the GitHub App token, which will correctly trigger subsequent workflow runs. LGTM.

So an LGTM is coming and I'll try to get this in before I go to sleep tonight.

[baogorek]

Left a note about Claude's anxiousness about a token carrying over, but an LGTM from the human.

[juaristi22]

There are other workflow files like reusable_tests.yaml that use similar tokens like secrets.POLICYENGINE_US_DATA_GITHUB_TOKEN or code_changes.yaml (which also seems responsible for publishing), that might also be affected by this. I'm not sure whether we want to trigger the entire test suite again on main (considering costs) now that we have the constraint that PRs need to be approved before merging. It might be worth reviewing the entire workflow now that running the pipeline has come in?

(Eg, the test suite was also responsible for publishing datasets, but now the pipeline run also does that, we might want to decide on a single responsible step -- we are overwriting them anyway otherwise). What do you think @baogorek @anth-volk ?