Plugin Release

Cuts a versioned release of the Elixir/Phoenix plugin. Drives the full checklist from CLAUDE.md (Release + Versioning) so every release is consistent. Contributor tooling, not shipped in the plugin.

Iron Laws, Never Violate These

1. NEVER release on a red make ci, the gate runs BEFORE committing. No green, no release.
2. FOUR TAGS PER RELEASE, vX.Y.Z plus phx--vX.Y.Z, ecto--vX.Y.Z, lv--vX.Y.Z from claude plugin tag (what dependency ranges resolve against). Tag only the release commit.
3. THREE NUMBERS MUST MATCH, plugin.json version == CHANGELOG heading == git tag (vX.Y.Z). Verify before pushing.
4. CONFIRM BEFORE PUBLISHING, pushing the tag and gh release create are outward-facing and hard to reverse. Stop and confirm with the user; show exactly what will be pushed/published first.
5. USERS ONLY UPDATE ON A plugin.json BUMP, never ship CHANGELOG/code changes without bumping the version, or installed users get nothing (cache).
6. ALWAYS leave a fresh empty ## [Unreleased], one [Unreleased] becomes one version heading; re-add an empty one on top.
7. NEVER force-push, git push --force is hook-blocked here. If history needs rewriting, the user runs it via !.
8. EVERY release body links the docs site, append the https://phxagents.dev footer. Releases are this project's one measured promotion lever (v3.0.1: 51 → 120 cloners in a day).
9. UPGRADE-BREAKING RELEASES LEAD WITH THE WARNING, if users must do anything beyond /plugin update, the release body opens with a > [!WARNING] block carrying the exact commands (see #135).

Step 0: Preconditions