ci(release): wire PREV_VERSION into ensure-version-increment.yml so the #540 cross-release guard actually runs

[MichaelTaylor3d]

Task

Wire scripts/package-version.sh's optional PREV_VERSION second argument into
.github/workflows/ensure-version-increment.yml so the #540 cross-release MSI ordering guard
actually runs on every PR, instead of sitting as dead capability.

Context

• fix(release): guard the MSI cross-release ordering hazard at a MAJOR bump #544 (2b5f4daf) added PREV_VERSION to scripts/package-version.sh: given the previous stable
  release, it folds it through the same MINOR-overflow mapping (Version scheme has exhausted the MSI minor field: every release from 0.256.0 ships with no Windows installer #521/fix(release)!: the 0.x version scheme hits the MSI 255 ceiling -- 3 legal versions left, 6 PRs already unbuildable #522) and refuses to emit a
  version whose MSI (major, minor, build) tuple compares LOWER than PREV_VERSION's — the guard
  for the specific hazard where a real MAJOR bump (e.g. 0.511.0 -> 1.0.0) can compare LOWER
  under msiexec's numeric ordering than an already-shipped overflow-carried version, aborting
  every user's upgrade with DowngradeErrorMessage.
• ci(release): make the MSI version-mapping check a required, fast-failing gate #542 (3584e2c9) made the script's single-argument validation a required check inside the
  Check version increment job.
• The gap: ensure-version-increment.yml's final step calls
  bash "$SCRIPT" "$HC" — one argument only. PREV_VERSION is declared, tested
  (scripts/tests/package-version.test.sh), and documented in the script's own header, but no
  caller in CI ever supplies it. The guard MSI mapping: a carried MINOR-overflow can outrank a later real 1.0.0, breaking upgrade at the 1.x transition #540 exists to add cannot fire.
• Confirmed via git show origin/main:.github/workflows/ensure-version-increment.yml on
  2026-09-03 at 2b5f4daf (current main tip) — the gap is real, not stale.

Done condition (finite, checkable)

• ensure-version-increment.yml resolves the latest stable (non-draft, non-prerelease) GitHub
  release version and passes it as PREV_VERSION to scripts/package-version.sh in the
  Check version increment job.
• A PR whose head version's MSI tuple compares LOWER than that resolved PREV_VERSION fails
  this required check, proven by an actual CI run (not a local script invocation).
• A PR with a legal increment still passes through the same job, proven by an actual CI run.
• The bootstrap case (no stable release resolvable) is handled explicitly, not silently swallowed.

Skill / reference

CLAUDE.md §2.4a (required-check semantics, check-merge-preconditions.sh), §1.10 (fail-closed vs
fail-open judgement — an API-read failure must never be conflated with "the thing being checked is
bad"). dig-ecosystem-workflow skill for the branch/PR mechanics.

Effort

Low-medium: mechanical CI wiring against an already-designed and already-tested script contract; the
only real judgement call is the bootstrap-case fail-open/fail-closed split, which is scoped and
argued in the implementing PR rather than escalated.

Evidence required

Two real GitHub Actions run URLs against a real PR: one showing the check fail on a deliberately
cross-release-violating version bump with the guard's own error text in the log, one showing it
pass on a legal bump — both through the actual workflow path, not package-version.sh invoked
standalone (that would repeat the exact mistake this ticket exists to fix: proving the script works
in isolation says nothing about whether CI ever calls it that way).

Closed by the PR that does this work, via Closes #<this>.