fix(desktop): recover missing get-windows binding

[helix4u]

What does this PR do?

Repairs Desktop packaging when get-windows@9.3.0 is installed without its Windows native binding.

The staging script previously ran npm rebuild get-windows. Because get-windows is optional, npm can report that rebuild as successful even when the package's native lifecycle fails and no napi-9-win32-unknown-x64 payload is produced. The resulting error then recommended the same ineffective command.

The staging path now resolves the package's own @mapbox/node-pre-gyp installer and runs install --fallback-to-build directly inside get-windows. It fails on a process error or non-zero exit, rescans lib/binding, and also fails accurately if the installer exits successfully without producing the requested Windows binding.

Related Issue

Closes #88251.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Replace the npm rebuild recovery hook with direct execution of @mapbox/node-pre-gyp from the installed get-windows package.
• Surface installer process failures instead of allowing npm's optional-dependency handling to hide them.
• Verify the requested binding exists and is staged after the installer completes.
• Remove both invalid manual recovery instructions.
• Cover successful recovery, installer failure, and a zero exit that produces no binding.

How to Test

From apps/desktop:

npm exec -- vitest run scripts/stage-native-deps.test.mjs --testNamePattern "win32 staging|native install"

The focused Windows staging tests pass: 6 passed | 24 skipped.

A disposable Windows verification also started with no lib/binding, downloaded the official v9.3.0/napi-9-win32-unknown-x64.tar.gz asset through the direct installer, produced node-get-windows.node, and classified it as a Windows binary.

The full test file reaches 28 passed | 1 skipped; its existing Darwin executable-mode assertion fails on Windows with 438 !== 493.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Missing-binding Windows verification:

before: false

node-pre-gyp ... napi-9-win32-unknown-x64.tar.gz

after: true, classification: win32

[OutThisLife]

Almost there — one ask before merge:

The new test get-windows native install invokes node-pre-gyp directly from the package root deepEquals the installer path against join(tmp, ...). On macOS require.resolve returns the realpath (/private/var/...) while tmp is /var/..., so the assertion fails even though the spawn is correct.

Compare against fs.realpathSync(installer) (or resolve both sides the same way). Happy to approve as soon as that's in.

[OutThisLife]

LGTM — the direct installer is the right recovery. I pushed the realpath compare so the macOS test matches require.resolve.