ci: create GitHub Release after publishing and tagging

[gregnazario]

Run gh release create with generated notes after the version tag is pushed. Tag pushes from GITHUB_TOKEN do not trigger other workflows, so the release step must live in this job. Checkout uses fetch-depth 0 so release notes can compare history.

[Copilot]

Pull request overview

This PR extends the existing PyPI publish workflow to also create a GitHub Release for the newly-pushed version tag, using autogenerated release notes based on the full git history.

Changes:

• Update actions/checkout to fetch full history (fetch-depth: 0) to support autogenerated release notes.
• Add a post-tag step that runs gh release create ... --generate-notes --verify-tag when a publish occurs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The inline comment is slightly inaccurate: the option is used with gh release create --generate-notes (not gh release --generate-notes). Updating the comment will avoid confusion when someone searches the CLI docs.

Suggested change

	fetch-depth: 0 # better gh release --generate-notes
	fetch-depth: 0 # better gh release create --generate-notes

[Copilot]

gh release create will fail (non-zero exit) if the release for this tag already exists, which makes workflow re-runs for an already-published version fail. Consider making this step idempotent by checking for an existing release (e.g., gh release view v$VERSION) and skipping or updating it instead of always creating a new one.

Suggested change

	gh release create "v${VERSION}" \
	--title "v${VERSION}" \
	--generate-notes \
	--verify-tag
	if gh release view "v${VERSION}" >/dev/null 2>&1; then
	echo "GitHub release v${VERSION} already exists; skipping creation."
	else
	gh release create "v${VERSION}" \
	--title "v${VERSION}" \
	--generate-notes \
	--verify-tag
	fi