<!--pre-commit.ci start-->
updates:
- [github.com/tox-dev/pyproject-fmt: v2.21.1 →
v2.21.2](tox-dev/pyproject-fmt@v2.21.1...v2.21.2)
<!--pre-commit.ci end-->

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

GraalPy reports "GraalVM" for `platform.python_implementation()` and
"graalpy" for `sys.implementation.name`, so this canonicalizes on
"graalpy".

The news fragments under `docs/changelog/` were never consumed because
the project shipped the PyPI publish workflow without the towncrier
config, template, rolled-up changelog, or release script that drives
them. Tags were being cut by hand and `urls.Changelog` pointed at GitHub
auto-generated notes, leaving the `.rst` fragments as dead weight that
risked double-counting on every release.

This ports the full release pipeline from `tox-dev/tox`. A release is
now a single `workflow_dispatch` click: `prepare-release.yaml` computes
the next version (auto-detecting major/minor/patch from
`breaking`/`feature` fragment counts), then `tox -e release` runs
`tasks/release.py`, which invokes `towncrier build`, commits the
assembled `docs/changelog.rst`, tags, force-pushes `main`, and opens the
GitHub release. The existing tag-push `release.yaml` handles PyPI
publishing unchanged. 🚀

`docs/changelog.rst` is backfilled for 1.0.0 through 1.3.0 from git
history so the rendered changelog is a single source of truth rather
than splitting between Sphinx and GitHub Releases. The `65.feature.rst`
fragment is dropped because that work already shipped in 1.3.0 via PR
#71. `sphinxcontrib-towncrier` renders unreleased fragments as a draft
section in the Sphinx build.

Operationally, this requires a `RELEASE_PAT` secret and a `release-auth`
GitHub environment, both used by the new `prepare-release.yaml`
workflow.