chore/post-release-cleanup: Rewrite CHANGELOG for v1.9.12, add workflow_dispatch, fix README

[vedanthvdev]

What happened

PR #23 intended to cut v1.10.0, but axion-release ignored the release-1.10.0 marker tag and cut v1.9.12 (default patch auto-increment). The release-1.10.0 marker was created by ./gradlew markNextVersion -Prelease.version=1.10.0, which is what the README's Versioning table told me to run — except that command only influences currentVersion's display output. The release task itself still follows incrementPatch unless -Prelease.version=X.Y.Z is passed at release time, which the workflow did not do.

v1.9.12 is already live on the Gradle Plugin Portal and on GitHub Releases with the intended content (same as what was planned for v1.10.0). Unpublishing from the Portal isn't supported, and publishing both v1.9.12 and v1.10.0 with identical content would be confusing, so this PR accepts v1.9.12 as the release and fixes the three things that actually need fixing.

Three paired fixes

1. CHANGELOG.md rewritten to match reality

The v1.10.0 entry is gone. In its place:

• A proper [1.9.12] entry scoped to what actually landed (this CHANGELOG itself, the README fix, and the workflow dispatch entry point). Framed honestly as a metadata-and-pipeline release.
• A Release history section for v1.9.8 → v1.9.11 that aggregates the v2 Phase 1+2 story across the patch releases it actually shipped in, linking to GitHub Releases' auto-generated notes for per-tag detail.
• An [Unreleased] placeholder so future PRs have an obvious place to add entries.

2. release.yml gains a workflow_dispatch entry point

workflow_dispatch:
  inputs:
    version:
      description: 'Explicit release version (e.g. 1.10.0). Leave empty for default patch auto-increment.'
      type: string
      required: false
      default: ''

The release step now passes -Prelease.version=\$RELEASE_VERSION_INPUT only when that input is non-empty. On every normal master push, inputs.version is empty and the command reduces to exactly the old form, so the auto-patch flow is untouched. On manual dispatch, the explicit version wins.

3. README Versioning table replaced

The old table recommended ./gradlew markNextVersion -Prelease.version=X.Y.0 for forcing minor/major bumps. That command does not do what the table claimed. The new table:

• Sends operators to Actions → Release → Run workflow → fill version for minor/major bumps (or the gh workflow run equivalent from a terminal).
• Keeps the "merge to master → patch release" flow as the default.
• Adds a negative-result footnote explaining what markNextVersion actually does, so the next reader doesn't repeat the mistake.

Stray tag cleanup (not in this diff)

Two stray tags from the failed attempt were removed out-of-band:

• release-1.10.0 — deleted from remote + local.
• v1.10.0-alpha — never made it to remote (local-only artifact from markNextVersion running on a non-master branch where versionCreator appends -alpha); deleted locally.

Test plan

• ./gradlew check green with --rerun-tasks (fresh, not cached).
• release.yml parses as valid YAML.
• Remote tag list is clean: git ls-remote --tags origin shows no v1.10.0-alpha or release-* entries.
• After merge, the normal push-to-master release workflow still cuts a patch (v1.9.13) from this PR's content. Expected, since the diff is still docs + workflow config.
• At some future minor bump, trigger the workflow manually with a version input and confirm it cuts the explicit version. That's the real validation of fix Fix security vulnerabilities and cross-module usage strategy (v1.3.0) #2; it doesn't need to happen in this PR.