fix(vtz): semver resolver — ^0.27.3 must not match 0.25.12 (#2738)

[viniciusdacal]

Summary

Fixes #2738. vtz install's semver resolver was producing lockfile entries like esbuild@^0.27.3 → 0.25.12, even though 0.25.12 clearly does not satisfy ^0.27.3. This caused every esbuild spawn across the monorepo to fail with Host version "0.27.3" does not match binary version "0.25.12" because the optional platform binaries still pinned to 0.27.3 while the host library resolved to 0.25.12.

Root Cause

Two fail-open paths in native/vtz/src/pm/resolver.rs:

1. Lockfile fast path in resolve_one_task (~line 262) trusted any pinned version under the matching name@range key without verifying the pin still satisfies the range. A stale entry left over from a prior install or registry-state change was silently reused.
2. Root-dep wiring in graph_to_lockfile (~line 526) looked up the hoisted package by name only, then wrote a lockfile entry pointing at whatever hoisted version happened to be present — even if it was out of range.

The low-level resolve_version() and node_semver itself were already correct — the bug was purely in the reuse / wiring glue that bypassed the satisfies-check.

Fix

Two new helpers, both in resolver.rs:

• version_satisfies_range(version, range) — thin wrapper over Range::parse(...).satisfies(Version::parse(...)) returning false on parse failure (fail-closed).
• lockfile_entry_satisfies_range(entry, range) — same, but treats github: and link: specs as always-valid since they're pinned outside semver.

Applied at both bug sites:

• The lockfile fast path now also requires lockfile_entry_satisfies_range(entry, range) before reusing a pinned version. A failing check falls through to a fresh registry resolve.
• graph_to_lockfile's hoisted-by-name lookup is replaced with hoisted-by-name-and-range.

Test Strategy (TDD)

All tests in native/vtz/src/pm/resolver.rs, ran cargo test -p vtz --lib to confirm red → green.

• test_version_satisfies_range_caret_zero_x — ^0.27.3 must reject 0.25.12 / 0.28.0 and accept 0.27.3 / 0.27.5.
• test_version_satisfies_range_tilde — same bounds for ~0.27.3.
• test_version_satisfies_range_explicit — >=0.27.3 <0.28.0 accept/reject.
• test_resolve_version_caret_rejects_lower_minor — ^0.27.3 against a version list containing 0.25.12 must pick 0.27.3.
• test_lockfile_entry_satisfies_for_current_range_rejects_stale — a pinned 0.25.12 under the ^0.27.3 key must fail the guard; 0.27.3 passes.
• test_graph_to_lockfile_rejects_hoisted_version_outside_range — confirmed RED on the prior code path; GREEN with the fix.

E2E Verification

Rebuilt the release binary (cargo build --release -p vtz), linked via scripts/link-runtime.sh, cleared ~/.vertz/cache/npm/store/esbuild* + @esbuild+*, ran vtz install:

Before: esbuild@^0.27.3: version "0.25.12" (WRONG)
After: esbuild@^0.27.3: version "0.27.7" (CORRECT — highest in [0.27.3, 0.28.0))

And node_modules/.bin/esbuild --version now prints 0.27.7, matching the installed package version.

Quality Gates

• cargo test -p vtz --lib — 3456 passed, 0 failed
• cargo clippy -p vtz --all-targets -- -D warnings — clean
• cargo fmt --all -- --check — clean

Test Plan

• Rust unit tests pass
• Rust clippy clean with -D warnings
• Rust fmt clean
• Live vtz install produces correct esbuild@^0.27.3 → 0.27.x lockfile entry
• node_modules/.bin/esbuild matches installed package version
• CI green

🤖 Generated with Claude Code