feat(build)!: derive the version from git, and adopt the verified release flow

[jimisola]

What & Why

Migrates this repo to the reworked org release flow in
reqstool/.github#66.

The old arrangement stopped at a draft. A human clicked Publish, and only then did
the publish workflows run — so everything that verified a release ran after it was already
public, and a failure meant a bad release was live.

Now the release is created as a prerelease and promoted only once everything that can
fail has succeeded. A prerelease rather than a draft because a draft is invisible to the
verification too (/releases/tags/<tag> 404s unauthenticated), while a prerelease is
readable by exact tag and still excluded from /releases/latest.

prepare  ->  lint + build  ->  [approval]  tag  ->  ...  ->  publish  ->  promote

The confirmation step is an environment approval on the job that tags, reached after
lint and build are already green — so a reviewer approves something verified rather than a
version string.

The version is no longer typed by hand. It is auto-detected from Conventional Commits;
passing one that disagrees requires force, which is the guard that catches "meant 0.3.0,
typed 0.2.0" before it becomes a tag. prerelease: rc cuts a release candidate — verified
exactly like a release, but never promoted to latest.

dry-run defaults to on: dispatching Release shows the resolved version, the generated
notes, and the raw commits they came from, without tagging or creating anything.

See RELEASING.md for the
full flow.

Author checklist

• actionlint clean
• Conventional Commit title, DCO sign-off
• No behaviour removed without a replacement

Test Plan

Merge order matters: this cannot merge before reqstool/.github#66. The workflows it
calls do not exist on main until that lands.

After merging:

1. Dispatch Release with dry-run left on. Confirm the job summary shows the resolved
   version, the notes, and the commit list — and that no tag or release exists afterwards.
2. Dispatch with prerelease: rc and dry-run off. Confirm it pauses for approval, then
   produces a prerelease with its artifacts attached, and that /releases/latest is
   unchanged.
3. Only then cut a real release with prerelease: none.

Note on pinning

Workflows are referenced at @main rather than a commit SHA, because the SHA does not exist
until #66 is squash-merged. Re-pinning to that SHA is a follow-up.

The version now comes from git

Replaces axion-release with io.github.jimisola.git-dyn-semver. Both derive the version from git tags, so this is not a change of principle — it is the plugin the rest of the org’s Gradle builds use, and it applies Conventional Commits bump logic to compute the next version rather than only reading the last tag. Pure JGit, no git CLI required.

Verified locally: tagging 9.9.9 makes ./gradlew printVersion print exactly 9.9.9; off-tag it yields {next}-{distance}-SNAPSHOT.

./gradlew publishPlugins builds from the tag itself, so the release flow has no separate build-and-attach step. java-publish-to-gradle.yml asserts the resolved version matches the tag before publishing, which catches the one failure that matters here: a shallow clone, which makes the plugin compute a version rather than fail.

Breaking: the version is computed by a different plugin. An off-tag build’s version string changes shape ({next}-{distance}-SNAPSHOT, not axion-release’s). Tagged builds are unaffected.