release.yml tags the squashed-away changelog commit — release tags never land on main; versions regress (v0.5.0→v0.4.1), wrong notes, silent-skip risk #11826

Umbrella: #11825 (Task 2)

Bug

release.yml creates the release tag on the changelog commit it makes during the run, then lands that commit on main via a squash-merged PR (#10845 flow). The squash produces a different SHA, so every release tag since v0.4.0 points at a commit that is not an ancestor of main:

$ git merge-base --is-ancestor v0.4.1 origin/main; echo $?   # 1 — NOT on main
$ git merge-base --is-ancestor v0.5.0 origin/main; echo $?   # 1 — NOT on main
$ git rev-list -n1 v0.4.1   # f8a05257c "chore(release): changelog and fragments for v0.4.1"
$ git rev-list -n1 v0.5.0   # 1ccdf46ea "chore(release): changelog and fragments for v0.5.0"
$ git describe --tags origin/main   # v0.4.0-749-g230255f0f  ← cliff sees v0.4.0 as latest

Consequences (all observed)

1. Versions went backwards: v0.5.0 released 2026-06-28, then v0.4.1 released 2026-07-15 — git-cliff computes the bump from v0.4.0 (the last tag still reachable from main), ignoring the newer off-main tags.
2. Wrong release notes: the v0.4.1 GitHub Release body lists June-era PRs (fix(ui): source Knowledge Manage host dropdown from node registry, not hardcoded VM0-5 (#10505) #10559–fix(ci): always report required 'Unit & Integration Tests' context (skip-success shim) (#10527) #10586) instead of the July work actually promoted — the notes range starts at v0.4.0 every time.
3. Silent skip risk: the "Check if release needed" step treats any existing tag named like the computed next version as "no release needed". A future feat-driven bump from v0.4.0 computes v0.5.0, which exists (off-main) → the promotion produces no release at all, silently.

Fix (single PR, .github/workflows/release.yml)

1. Tag the pushed main commit: git tag -a "$VERSION" -m "Release $VERSION" "$GITHUB_SHA" — not the ephemeral changelog commit. The changelog commit still lands via the existing PR flow; the tag stays an ancestor of main forever.
2. Monotonic version guard in the check step: after git-cliff computes NEXT, compare against the highest existing v* tag (sort -V). If NEXT ≤ highest, release patch-bump(highest) instead — versions can never go backwards or collide with off-main legacy tags (v0.4.1, v0.5.0).
3. Correct "no release needed" detection: compare NEXT against the latest ancestor tag (git describe --tags --abbrev=0) instead of "does a tag with this name exist" — collision with a non-ancestor tag must not skip the release.

Acceptance Criteria

• Release tag created by the workflow points at the commit pushed to main (verifiable: git merge-base --is-ancestor <tag> main)
• Computed release version is strictly greater than every existing v* tag (monotonic)
• A version collision with a non-ancestor legacy tag does not skip the release
• Next Dev_new_gui → main promotion publishes a release whose notes cover only the newly promoted range