Cut releases with commitizen instead of by hand

[davertor]

TLDR: The version is mirrored in five files and the bump was manual, so a merge could land a feature without moving it. cz bump now reads the Conventional Commits since the last tag, works out the increment, rewrites all five and tags.

uvx --from commitizen cz bump --yes && git push --follow-tags

• .cz.toml — the five mirrors (SKILL.md, both plugin.json, marketplace.json, the README badge), tag_format = "v$version", and bump_message = "chore(release): $new_version" so release commits keep the shape this repo's history already uses. commitizen's default bump: is not one of the types CONTRIBUTING.md allows.
• Not a dependency. It runs through uvx, so nothing is installed and no manifest mentions it. The stdlib-only rule covers the scripts that ship to users; a tool the maintainer runs at release time is a different thing, and the config says so.
• The CHANGELOG stays hand-written (update_changelog_on_bump = false). The entries here are prose explaining what changed and why; the generated form is a list of commit subjects. cz changelog --dry-run still prints them grouped by type, which is a useful checklist to write the section from.
• AGENTS.md — new, because the repo had none. Leads with the release step, since that is the thing that was being missed, and adds the handful of conventions that are easy to get wrong from the outside: stdlib-only, --selftest instead of a test suite, Conventional Commits (which the release tooling now reads), the note-as-database contract, and that colour and type come from themes.py.
• CONTRIBUTING.md gains a Releases section with the command and the rationale.

Verified in a throwaway clone: feat → minor, fix → patch, feat! → major; all five files rewritten; chore(release): X.Y.Z committed and vX.Y.Z tagged; the CHANGELOG untouched.

Needs one bootstrap step after merge: git tag v1.3.0 <main> and push it, so commitizen has a baseline to count from. The repo only has v1.0.0 today.