fix(workflows): stop one-commit release drift

[arnaudlh]

Summary\n- remove post-tag version/changelog mutation from release workflow\n- enforce release version invariant so tag vX.Y.Z must point to a commit already carrying X.Y.Z in version files\n- add guard to ensure tag-triggered releases run only for commits reachable from main\n\n## Why\nThe previous flow could publish release vX.Y.Z and then commit version updates afterward, causing source to appear one commit behind the release tag.\n\n## Validation\n- actionlint .github/workflows/git-ape-release.yml\n

[sendtoshailesh]

Summary: This PR removes the post-tag mutation path from git-ape-release.yml, adds an invariant check that the release commit already carries the target version in plugin.json and .github/plugin/marketplace.json, and keeps the packaging / GitHub Release / VS Code Marketplace publish flow intact.

Version invariant: The new check is solid for the stated goal. It compares all three version sources against the resolved X.Y.Z value, so standard releases, pre-releases like 1.2.3-rc.1, and multi-digit versions are handled correctly. This is a much better release invariant than mutating version files after the tag already exists.

Main reachability guard: The git merge-base --is-ancestor "$GITHUB_SHA" origin/main check is the right test for tag-triggered runs, including merge commits. However, it currently only runs for push events. workflow_dispatch can still be launched from a non-main branch/ref, pass the version invariant, and then create/push a release tag from a commit that is not reachable from main. That undermines the PR's stated guarantee. I think this guard needs to run for manual releases too (effectively unconditionally after checkout).

Deleted behavior: The large deletion is mostly the old post-release mutation block that re-bumped version files / updated CHANGELOG.md on main. Release notes generation, GitHub release creation, VSIX upload, and Marketplace publish are still present, so nothing essential to artifact publication was lost. The only notable behavior change is that CHANGELOG.md is no longer maintained by this workflow, which seems intentional here.

Concern / requested change: please apply the main-history guard to workflow_dispatch as well. Once that is fixed, the workflow looks merge-ready to me.

[arnaudlh]

@sendtoshailesh Addressed in 2bb671fa.

The main-history guard is now unconditional — I removed the if: github.event_name == push filter so it runs for workflow_dispatch too. Because the step sits before "Ensure release tag exists", a manual release launched from a non-main ref now fails the git merge-base --is-ancestor "$GITHUB_SHA" origin/main check before any tag is created or pushed, closing the gap you flagged.

I also renamed the step to "Validate release commit is on main history" and made the messages event-agnostic, since it no longer applies only to tag pushes.

Ready for re-review.

[sendtoshailesh]

Verified the follow-up commit fixes the remaining gap. The main-history reachability guard is now unconditional, so both tag pushes and workflow_dispatch runs must originate from a commit reachable from origin/main before any tag is created or reused. The version invariant check still runs afterward for both entry points, so manual releases can no longer bypass the release-commit/version synchronization guarantee. I also re-scanned the updated workflow and did not find any new blocking issues in this change.