fix(release): guard the MSI cross-release ordering hazard at a MAJOR bump

[MichaelTaylor3d]

DO NOT MERGE -- gate round in progress.

Task

Closes #540: scripts/package-version.sh's MINOR-overflow carry (added by #537, resolving #521 and #522) is
monotonic for dig-node's whole MAJOR==0 lifetime, but the SPEC itself flagged a cross-release
hazard it cannot see: a carried release like 0.511.0 (MSI 1.255.0) can compare HIGHER under
msiexec's numeric ordering than a later, perfectly legal 1.0.0 (MSI 1.0.0). msiexec would
either refuse the "upgrade" (DowngradeErrorMessage) or leave the older payload installed.

Measurement first

Checked every published dig-node tag: the highest MINOR ever shipped is 252 (0.252.11), well
under the 255 threshold where the carry even activates. The hazard has never been reached. But
"never reached yet" is not "unreachable" -- minor climbs every feature release and is 3 bumps from
255 -- so I did not close this as not-applicable; I closed the gap before it can be reached.

What changed

scripts/package-version.sh gains an optional second argument, PREV_VERSION (the previous
stable release's bare X.Y.Z). When supplied, the script folds it with the identical rule and
refuses to emit a version whose MSI tuple compares LOWER than PREV_VERSION's -- turning "pick a
MAJOR-bump number high enough to clear history" from an unchecked human decision into a machine
check. An EQUAL tuple is NOT rejected (that's the existing AllowSameVersionUpgrades="yes"
same-version-upgrade case, not a downgrade).

Omitting the argument is byte-for-byte unchanged -- all three existing package.yml callsites
pass a single arg today and are untouched by this PR.

Sequencing with #542

#542 (open, draft, "gate round in progress") adds a step to ensure-version-increment.yml's
required Check version increment job that calls package-version.sh with the head version only.
That job already checks out both main and the PR head, so wiring this guard in is a one-line
follow-up once #542 merges: pass main's Cargo.toml version as the second argument to the same
call. I deliberately did NOT touch ensure-version-increment.yml in this PR to avoid conflicting
with #542's in-flight branch on the same file -- @mt-dev/orchestrator, please sequence: land #542,
then a 1-line addition wires this guard into that job.

Also fixed (cheap, same files already open)

#521/#522 were referenced as dig_ecosystem#521/dig_ecosystem#522 in the script, its test
file, and SPEC.md -- those are dig-node's OWN issues (verified: "Version scheme has exhausted the
MSI minor field..." / "fix(release)!: the 0.x version scheme hits the MSI 255 ceiling..."), not the
unrelated dig_ecosystem tickets of the same numbers. Corrected to bare #521/#522 in the three
files this PR already touches.

Verification

Test COUNTS, not exit status:

• scripts/tests/package-version.test.sh: 58 ok / 0 fail (was 49 before this PR; +9 new cases
  for the cross-release guard).
• Revert-proof: reverted package-version.sh to origin/main's version (script only, kept the
  new tests) and re-ran -- 4 genuine failures, including the ticket's exact scenario:
  FAIL the ticket's own example -- 0.511.0 outranks a naive 1.0.0: accepted 1.0.0 over prev 0.511.0 (exit 0). Restored the fix -> back to 58/0. The test suite demonstrably catches the defect.
• Manual spot checks:
  • package-version.sh 1.0.0 0.511.0 -> package-version: '1.0.0' (MSI 1.0.0) compares LOWER than the previous release '0.511.0' (MSI 1.255.0) ... exit=1 (the hazard, refused)
  • package-version.sh 2.0.0 0.511.0 -> msi_product_version=2.0.0 exit=0 (a number that clears
    history, accepted)
  • package-version.sh 0.511.0 (no 2nd arg, an existing callsite shape) -> unchanged,
    msi_product_version=1.255.0 exit=0
• shellcheck on both touched shell files: only pre-existing SC2016 info notes on lines this PR
  did not touch (deliberate single-quoted injection-test literals).

Version bump

0.254.40 -> 0.254.51 (patch -- script/test/spec hardening, no behaviour change for any existing
caller). Re-bumped once: main advanced to 0.254.41 via #535 while this PR was in flight, so I
merged origin/main forward (not rebase) and re-bumped. The queue across five open PRs sequences
this one last on purpose -- #542 0.254.42, #539 0.254.43, #543 0.254.44, #536 0.254.50, this PR
0.254.51 -- so by the time this merges, #542 (touching the same ensure-version-increment.yml this
PR's follow-up targets) is already on main. Root Cargo.toml + cargo update -w --offline
(confirmed --dry-run -> Locking 0 packages after the real update; version read back from
Cargo.toml on disk, not the commit log).

Closes #540