Manually curated releases

Auto-generated changelog leave much to be desired. We will replace knope with manual changelog curation via the following process.

Target process

1. Version is one static string in pyproject.toml, bumped by a human.
2. Changelog is written by humans, one entry per user-visible change, accumulating under ## Unreleased (Keep a Changelog format).
3. Release is a PR. Bump the version, rename ## Unreleased to ## 4.19.0 — 2026-09-14. Review it, merge it.
4. Merging the release PR is the whole release for rc and dev builds. CI detects the version change on master, creates the tag and GitHub Release, and publishes. No manual tagging, no forms, no second click. A final X.Y.Z release is tagged and released the same way automatically, then waits on one approval click at the pypi-release environment before the PyPI upload.
5. Release candidates are the same flow with an rc version (4.20.0rc1), detected and marked prerelease automatically.
6. Dev builds are dispatched manually from the GitHub UI on any branch, including unmerged PR branches.

Though we are moving away from knope, conventional commits are required for merging and encouraged for development pre-merge.

Start with pyproject.toml and locate the current knope and CI release entry points. Compare them with the target process in the issue, including version and Unreleased handling, release-candidate and dev-build dispatch, automatic tagging and publishing, and PyPI approval; done means those flows work without manual tagging or release forms.