Add tag-triggered GitHub Actions workflow to publish releases to PyPI

[adulau]

Motivation

• Automate publishing of packaged releases when a v* tag is pushed so releases and PyPI publishing are consistent and reproducible.

Description

• Add .github/workflows/release.yml which triggers on push of tags matching v* and grants contents: write and id-token: write permissions.
• Add a build job that checks out the repo, sets up Python with actions/setup-python@v5, installs build tooling, runs python -m build, and uploads dist/* as artifacts using actions/upload-artifact@v4.
• Add a publish-pypi job that downloads the built artifacts and publishes them using pypa/gh-action-pypi-publish@release/v1 scoped to a pypi environment.
• Add a github-release job that downloads the artifacts and creates a GitHub release with the distributions attached using softprops/action-gh-release@v2.

Testing

• Ran git diff --check which reported no whitespace errors and passed.
• Ran a local workflow sanity check script that validated required action identifiers and it passed.
• Attempted python -m build locally which failed because the build module was not available in the environment.
• Attempted python -m pip install --user --upgrade build && python -m build which failed due to network/proxy 403 Forbidden when fetching build.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e5b7a96876

ℹ️ 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]

Enforce tag/version consistency before publishing

When any v* tag is pushed, this workflow builds and publishes the static version declared in pyproject.toml (0.1.0 currently) without checking that it matches the tag. If a maintainer pushes v0.2.0 before bumping the project metadata, PyPI will receive the old version and the GitHub release for v0.2.0 will attach artifacts named for 0.1.0; add a pre-publish check comparing ${GITHUB_REF_NAME#v} to the built package metadata version or derive the version from the tag.

Useful? React with 👍 / 👎.