fix(release-script): stop the cut when a git add, commit, tag or push fails

[DemchaAV]

Why

PowerShell does not stop on a native command's non-zero exit, and cut-release.ps1 ran its release git add, git commit, git tag and git push bare. On the 2.4.0 cut a stale .git/index.lock failed the release add and commit. The script printed commit: Release v2.4.0 anyway, and Step 7 tagged fa104ba5, the commit before the release. -SkipPush kept that tag off origin; without it the wrong commit would have been tagged and pushed, and the tag would have started the publish workflows.

What changed

• scripts/cut-release.ps1 — Invoke-Git runs git and throws git <args> failed (exit N); nothing after it ran. on a non-zero exit. All eight repository-changing calls go through it: add, commit, tag and push in the release path, and add, commit and push in -PostReleaseOnly. A release commit with nothing staged now stops the cut too, where it used to pass silently.

• ReleaseScriptGitExitCodeGuardTest (core, documentation guards) — fails on any bare git add|commit|tag|push|reset|checkout|merge|rm statement in the script, and on an Invoke-Git that no longer throws on $LASTEXITCODE.

• release-script-check.yml — new step A failed git mutation stops the cut. It lifts Invoke-Git by AST and runs it against a throwaway repository holding index.lock:

  • a bare-git control shows the harness does not throw on its own;
  • add and commit under the lock stop, naming the call;
  • without the lock, a path and a message containing spaces arrive intact;
  • an existing tag and a push with no remote stop.

  The step resets $LASTEXITCODE at the end, because the Actions pwsh wrapper exits with it and the last git call fails on purpose.

• docs/contributing/release-process.md — the Step 6–8 behaviour, and a troubleshooting row for a held index lock. The row says what a Step 6 stop versus a Step 7 stop leaves behind.

Why not $PSNativeCommandUseErrorActionPreference = $true for the whole script: it would turn every native non-zero exit into an exception, including the git status / rev-parse probes and Maven calls the script already checks itself. That changes far more than this bug.

Lane: build / release tooling. No runtime code, no public API.

Verification

• ./mvnw -B -ntp test -f core/pom.xml -Dtest='com.demcha.documentation.**' — 145 tests, 0 failures, BUILD SUCCESS (2 new).
• Sabotage, each caught by the check that owns it:
  • git commit -m $commitMsg restored bare → everyGitMutationGoesThroughTheCheckedHelper fails, naming line 1897;
  • the helper's throw replaced by Write-Host → theHelperThrowsOnANonZeroExit fails, and so does the new workflow step.
• The workflow step, run locally inside a reproduction of the Actions pwsh wrapper ($ErrorActionPreference = 'stop' … exit $LASTEXITCODE): exit 0 as written, exit 1 with the throw removed. Before the $LASTEXITCODE reset it exited 128 despite passing every check.
• cut-release.ps1 -Version 2.4.1 -Branch develop -DryRun -SkipShowcase and -PostReleaseOnly -Branch develop -DryRun both complete with exit 0.