ci: trigger release + PyPI publish on tag push

[lesnik512]

What

Makes modern-di's release flow tag-driven. Pushing a semver tag now both publishes to PyPI and creates the matching GitHub Release in one job. Renames publish.yml → release.yml to reflect the expanded role.

Before: you manually publish a GitHub Release, which fires publish.yml → just publish.
After: git push origin 2.19.2 → publish to PyPI + create the Release. No manual release-creation step.

Key points

• Old on: release: published trigger removed. Mandatory, not cosmetic: the workflow now creates a published Release itself, which would re-fire that trigger and double-publish. The tag is the sole entry point.
• No in-workflow CI gate — by convention a tag is only cut off a green main.
• PyPI runs first (irreversible). If just publish fails the job stops and no GitHub Release is created advertising a version that never reached PyPI. just publish already derives the version from $GITHUB_REF_NAME, which is the tag under a push: tags event, so it works unchanged.
• Pre-releases supported via PEP 440 tag form (2.0.0rc1, 2.0.0a5) — flagged as GitHub pre-releases so they aren't marked "Latest". The historical 2.0.0-alpha.5 form is intentionally not matched (not PEP 440; uv version would reject it).
• Release description comes from planning/releases/<tag>.md when present (verbatim, no auto-changelog appended), else GitHub's generated notes.

Docs

Documents the now-canonical tag-driven process in the CLAUDE.md Workflow section ("Cutting a release (maintainers)"). Kept out of docs/dev/contributing.md since cutting a release is a maintainer-only job, not a contributor step.

Validation

• YAML parses; job/step structure verified.
• Tag patterns stable (2.19.2) and pre-release (2.0.0rc1) are disjoint — no double-trigger.
• Prerelease-flag logic spot-checked: 2.19.2→false; 2.0.0rc1/2.0.0a5/2.0.0b1→true.

🤖 Generated with Claude Code