ci: fix PyPI publish 403 by granting OIDC perms to changelogs job

[brendanjryan]

Problem

Every release commit since v0.6.0 has failed to publish to PyPI with 403 Forbidden:

pympp v0.7.0 ... ✗
  publish failed: twine upload failed (exit code exit status: 1):
  ERROR    HTTPError: 403 Forbidden from https://upload.pypi.org/legacy/

PyPI shows 0.6.0 (Apr 7) as the last published version — 0.6.2, 0.6.3, and 0.7.0 never landed.

Root cause

The wevm/changelogs action runs twine upload itself from inside the release job. PyPI Trusted Publishing requires:

• id-token: write permission (to mint an OIDC token)
• The job to run in the release environment (matching the publisher entry)

The release job had neither — only contents: write and pull-requests: write. So the OIDC claim either wasn't issued or didn't match the trusted publisher entry, and PyPI returned 403.

The separate publish job below was correctly configured but never ran because release errored out, and is redundant since changelogs already handles the upload.

Fix

Add environment: release and id-token: write to the release job so the OIDC token issued matches the PyPI trusted publisher entry (tempoxyz/pympp + publish.yml + release).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ad950ba81c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid triggering a second PyPI upload for same release

Granting release OIDC permissions here makes wevm/changelogs able to publish from the release job, and that action sets published=true when it uploads. In this workflow, that output immediately triggers the separate publish job (if: needs.release.outputs.published == 'true'), which attempts to upload the same version again via pypa/gh-action-pypi-publish; its default is to fail on duplicates (skip-existing is disabled by default), so successful releases can still end in a failed workflow run.

Useful? React with 👍 / 👎.