Add the git primitives a release pipeline checks against

[MihaiBojin]

Four assertions and two accessors that a release pipeline runs before it publishes
anything, so the checks live here once rather than as a copy per repository. Three
byte-identical copies of check-tag-version.bash exist across template-python-package,
jazzy-fish and MihaiBojin/worktrees#2 today, and the helper under them has already
drifted: jazzy-fish's get_tags_at_head lost the 'v*' filter, so a chart tag on the same
commit outranks the release tag.

The remote is resolved, not assumed

git::remote answers from checkout.defaultRemote, then the current branch's remote, then
the sole remote, and refuses when several exist and nothing says which, naming the fix:

$ rt git::remote
origin

origin is a convention rather than an answer. On a fork it names the fork, whose tags are
not the project's releases. remote.pushDefault stays unread because it says where commits
go rather than where they come from, and those differ in exactly that case.

git::latest_version asks git::remote instead of reading remote.origin.url. CI
checkouts have one remote named origin, so the answer there is unchanged.

The version is passed in

$ rt git::assert_tag_version "$(uv version --short)"
Tag matches the version: 0.1.0

$ rt git::assert_tag_version 9.9.9
ERROR: tag/version mismatch, refusing to continue.
ERROR:   tag(s) at HEAD: v0.0.16 v0
ERROR:   version given:  9.9.9

Reading pyproject.toml here would mean a TOML parser, and python::project_name was
deleted in #35 for exactly that cost: 9 recursive Homebrew formulae and 126MB for one
function nobody called. Every ecosystem already has a one-liner, so the caller runs its own
and this stays dependency-free.

Accepts 1.2.3 and v1.2.3. A commit can carry several tags, so one match is enough.

Uncertainty is a refusal

$ rt git::assert_tag_free v0.0.16
ERROR: tag 'v0.0.16' already exists on 'origin'.
ERROR: releases do not move tags; pick the next version.

$ rt git::assert_tag_free v9.9.9
Tag 'v9.9.9' is free on 'origin'.

An assertion rather than a predicate, because git::tag_exists X || release fires on every
non-zero status, so no network, no permission and no remote all read as "the tag is free".
Only git's exit 2, its "no such ref", means carry on. That is the bug jazzy-fish's
tag-release.bash carries today, where 2>/dev/null hides the difference.

The retry that used to need --force

git::release reuses a tag that already points at HEAD:

$ git::release v1.0.0          # after a run whose push failed
Tag 'v1.0.0' already points at HEAD; reusing it.

$ git::release v1.0.0          # HEAD has moved since
ERROR: tag 'v1.0.0' already exists and points at 40f8d88, not HEAD (e317459)
ERROR: delete it or pick another version; releases do not move tags

git tag -a fails on an existing tag even when it names the same commit, and the only flag
that cleared it was --force, which is also handed to the push. So the retry was either
blocked or it moved a published tag. --force keeps meaning the remote.

rt on PATH

install.sh links rt alongside releasetools. Until now rt came only from the
Homebrew formula, so uses: releasetools/cli@v0 followed by rt ... failed while the same
command worked on a brew machine.

Not here

The github::, changelog::, net:: and release:: commands are stacked on top of this
branch, along with removing github::get_version and declaring gh in
github::_internal_check_deps. Nothing in this branch calls gh.

#38 brings git::version_tag and git::latest_version into line with the prefix rule the
new commands follow. Doing it here would mix a breaking rename into a branch that only
adds.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Lp5si1kwiFK1w52a6usA33