All Windows CI jobs fail: due to `windows-latest` now shipping Visual Studio 2026

Nobody has claimed this yet.

## Summary

Every `windows-latest` job in `ci.yml` fails at `configure`. The GitHub Actions `windows-latest` image now serves Visual Studio 2026 (18.x) and no longer carries Visual Studio 2022.

There are two independent causes, split across the matrix:

1. **Node 20.x** — the bundled node-gyp (10.1.0) predates VS 18 support and cannot detect the installed compiler at all.
2. **Node 24.x and `lts/*`** — the bundled node-gyp (12.4.0) detects VS 2026 correctly, but [`test/run.util.js:63`](../test/run.util.js#L63) hardcodes `--msvs_version=2022`, so the detected toolchain is rejected.

## Evidence

Failing run: https://github.com/mapbox/node-pre-gyp/actions/runs/35073143327 (all three Windows jobs fail)

### The image no longer has VS 2022

`windows-latest` resolves to the `win25-vs2026` image:

- Operating System: Microsoft Windows Server 2025
- Image Release: https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260907.229

### Cause 1 — Node 20.x: node-gyp cannot see VS 18

```
gyp ERR! find VS unknown version "undefined" found at "C:\Program Files\Microsoft Visual Studio\18\Enterprise"
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use
```

node-gyp gained VS 18 support in **12.0.0**. In `lib/find-visualstudio.js`, 12.4.0 has:

```js
if (ret.versionMajor === 18) {
ret.versionYear = 2026
return ret
}
```

This block is absent in 10.1.0 and 11.4.2, where the version ladder stops at `versionMajor === 17`. Verified by diffing `find-visualstudio.js` across 10.1.0, 11.4.2, 12.4.0 and 13.0.2.

Which node-gyp each job gets, via the bundled npm:

| Matrix entry | Node | npm | node-gyp | VS 18 detected? |
|---|---|---|---|---|
| `lts/-1` | 22.23.2 | 10.9.8 | 11.5.0 | No |
| `lts/*` | 24.21.0 | 11.19.0 | 12.4.0 | Yes |
| `latest` | 26.9.0 | 11.19.1 | 12.4.0 | Yes |

Only `lts/-1` (Node 22) is affected. These aliases float: `lts/*` moves to Node 26 when it enters LTS in October 2026, at which point `lts/-1` becomes Node 24 and the problem disappears on its own — but Node 22 is supported until 2027-04-30, so it needs handling until then.

### Cause 2 — Node 24.x / `lts/*`: hardcoded `--msvs_version=2022`

node-gyp 12.4.0 finds the toolchain without trouble, then rejects it only because of the pinned version flag:

```
gyp ERR! find VS checking VS2026 (18.9.12120.119) found at:
gyp ERR! find VS - found "Visual Studio C++ core features"
gyp ERR! find VS - found VC++ toolset: v145
gyp ERR! find VS - found Windows SDK: 10.0.26100.0
gyp ERR! find VS - "2026"
gyp ERR! find VS - looking for Visual Studio version 2022
gyp ERR! find VS - msvs_version does not match this version
gyp ERR! find VS could not find a version of Visual Studio 2017 or newer to use
```

The flag comes from [`test/run.util.js:63`](../test/run.util.js#L63):

```js
// Test building with msvs 2022
if (process.platform === 'win32') {
final_cmd += ' --msvs_version=2022 ';
}
```

Consistent with there being only one blocker on Node 24, it fails fewer tests (`not ok 4`) than Node 20 (`not ok 2`, `4`, `7`, `8`, …), which fails earlier and more broadly.

## Possible directions

**The question to settle first: should node-pre-gyp support building against VS 2026 generally, or is this only about making CI green?** Every option below is downstream of that.

Relevant to it: `engines` is `>=18`, and the README states support tracks the [Node.js release schedule](https://github.com/nodejs/release#release-schedule), retiring versions at EOL. **Node 20 went EOL on 2026-04-30**, so the matrix is currently testing an EOL release — which bears directly on how much the Node 20 breakage is worth working around.

- **Remove the `--msvs_version=2022` flag** from `test/run.util.js`, letting node-gyp auto-detect. Plausibly fixes Node 24 and `lts/*`. Does nothing for Node 20, which fails before the version check.

The flag looks incidental rather than deliberate. It was introduced as `--msvs_version=2015` with the comment "since that is more edge case than 2013" — the intent was to exercise a non-default VS version, and the current `2022` value arrived via a mechanical bump in #707. Hardcoding a version means the value needs updating every time the runner image moves, which is how this broke. Auto-detection removes that maintenance entirely.

Trade-off: `test/run.util.js:63` is the only reference to `msvs_version` under `test/`, so removing it drops the sole coverage of node-pre-gyp's `--msvs_version` pass-through ([`lib/configure.js:15`](../lib/configure.js#L15) lists it among `known_gyp_args`). If that path is worth testing, it would be better covered by an explicit unit test of argument forwarding than by a global flag on every Windows build.
- **Force a newer node-gyp for Node 20** (e.g. `npm_config_node_gyp` pointing at node-gyp ≥ 12). Would fix Node 20, but means CI no longer exercises the node-gyp that Node 20 users actually get — worth weighing, since that is part of what this package integrates with.
- **Drop Node 20 from the matrix**, since it is already past EOL and the README commits to retiring EOL versions. This removes Cause 1 entirely rather than working around it, leaving only the `--msvs_version=2022` flag to fix. Note this is a support-policy change, not just a CI change — `engines` is currently `>=18`.

Start with ci.yml and the failing Windows Actions run, then read test/run.util.js:63 and lib/configure.js:15 to understand the Visual Studio flag path. First resolve whether the project should support Visual Studio 2026 generally or only restore CI, including the Node 20 policy. Done means the chosen support behavior is covered appropriately and the Windows matrix passes.

Written by the indexing model from the issue text.