ci: auto-create GitHub Release on tag push

[nextgenusfs]

Adds a github-release job to python-publish.yml so pushing a version tag (e.g. v26.5.22) creates the GitHub Release automatically — no more manual release creation through the UI.

Why

The workflow already publishes to PyPI and TestPyPI on tag pushes, but the matching GitHub Release has been a manual step. Every existing release (v0.2.0 → v25.8.12) was hand-created.

What it does

New job runs only on tag pushes and only after publish-to-pypi succeeds:

1. Downloads the dists artifact built earlier in the same workflow run.
2. gh release create "$GITHUB_REF_NAME" --generate-notes — uses GitHub's auto-generated release notes (the **Full Changelog**: compare/... style that matches your existing releases).
3. gh release upload "$GITHUB_REF_NAME" dist/** — attaches the .whl and .tar.gz to the release.

Uses the default GITHUB_TOKEN with permissions: contents: write — no new secrets or PATs.

What it does NOT do

• No sigstore signing of artifacts (intentionally out of scope; can be added later).
• No draft releases — releases are published immediately on tag push.
• No CHANGELOG.md generation in the repo.

Behavior on non-tag pushes

The new job has if: startsWith(github.ref, 'refs/tags/'), matching the existing publish jobs, so it will appear as skipped (not failed) on every regular push to main.

Failure semantics

needs: publish-to-pypi means if PyPI upload fails, no release is created. You can then fix the issue and retry the workflow cleanly without an orphaned GitHub Release.

Verification

• python -c "import yaml; yaml.safe_load(open('.github/workflows/python-publish.yml'))" — valid YAML, 4 jobs present
• ⚠️ The end-to-end proof comes from the next tag push (v26.5.22): the Release should appear at https://github.com/nextgenusfs/gapmm2/releases with the wheel and sdist attached.

Single-file change, +34 / −0.

---

Pull Request opened by Augment Code with guidance from the PR author