Unpin windows-2022 runners → windows-latest after the VS 2026 migration settles

[IvanWng97]

Deferred from the Windows arc (#128, spec decision 7). windows-latest migrates VS 2022 → VS 2026 June 8–15, 2026 — exactly when the arc's CI landed, so both Windows jobs pinned windows-2022:

• .github/workflows/ci.yml → windows-test job
• .github/workflows/release.yml → the two *-pc-windows-msvc matrix rows

Once the migration is done and stable (check the runner-images repo announcements), switch both to windows-latest in one PR and watch one full windows-test run.

[IvanWng97]

Checked 2026-06-14 — NOT ripe yet, holding the pin

Researched the live upstream state (not just this issue's planned dates). The windows-latest → "Windows Server 2025 with Visual Studio 2026" migration is mid-rollout and not yet stable, so the unpin stays deferred.

Migration not done:

• Tracking issue actions/runner-images#14017 is still open (verified via API). Body: the switch "will be rolled out over a week beginning June 8, 2026 and will complete by June 15, 2026" and is gradual ("workflows will gradually switch over"). Today (June 14) is inside the window, one day before completion.

New image not stable — and one break hits us directly:

• #14215 "v143 build tool for ARM64 is missing" — open, maintainer still investigating (touched 2026-06-12). This lands on our aarch64-pc-windows-msvc release leg (release.yml:87, cross-links VC ARM64 on the x64 runner).
• Non-deterministic windows-latest during the window (sometimes VS2026, sometimes not — no common toolset).
• Also open/active: missing ATL/MFC v143 components, actions/cache@v5 silent failures, CMake generator string change, node-gyp/Win10-SDK regressions.
• Official mitigation during the window is exactly what we do: pin windows-2022.

Our blast radius (for when it's ripe): build is version-agnostic — rust-toolchain.toml pins only channel=stable; no vswhere/toolset/SDK/windows-2025 references in .github/, justfile, .cargo/, or build.rs. The flip is near-mechanical.

Re-check gate (pick up on/after 2026-06-16)

Re-evaluate one day past the June 15 completion date (let the staggered rollout settle), and gate the flip on ALL of:

• gh api repos/actions/runner-images/issues/14017 shows state: closed (or an explicit "rollout complete" maintainer note);
• #14215 (the ARM64 v143 break on our aarch64 leg) is closed/resolved;
• no fresh top-of-issue breakage on #14017 in the prior ~3 days (spot-check: no new "non-deterministic / ATL missing / 7z missing" reports).

The flip, when GO (exact edits)

• .github/workflows/ci.yml:167 — runs-on: windows-2022 → windows-latest; drop the carry-item comment at :165-166.
• .github/workflows/release.yml:85 and :87 — os: windows-2022 → windows-latest (both x86_64 + aarch64 legs); update the comment at :82.
• .github/workflows/release.yml:128 — verify the "7z is preinstalled on windows-2022" assumption holds on the new image (the only image-tooling dependency in the Windows path, used at :135); if 7z is gone, swap to PowerShell Compress-Archive.
• Post-merge: watch a full windows-latest CI run, AND workflow_dispatch/dry-run the Windows release legs to confirm both x86_64 + aarch64 build/link/package (the 7z step) on the VS2026 image before the next real release.

[IvanWng97]

2026-07-02 cleanup verification: cannot lift yet — windows-latest still resolves to Windows Server 2022 on GitHub's runner-images (the VS 2026 migration hasn't flipped the alias). Pin stays. Re-check at the next quarterly pass.

[IvanWng97]

Resolving — kept the unpin to windows-latest (done in #454)

#454 (merged 2026-07-03, 5ba66b3) flipped all three runners windows-2022 → windows-latest:
ci.yml:224 (windows-test), release.yml:89 + :91 (both *-pc-windows-msvc legs). Superseding my
2026-07-02 "pin stays" note above — after verifying the live image state, keeping the unpin is safe.

Why it's safe now (verified against the runner-images manifest, not just the tracking dates)

• windows-latest currently resolves to the plain Windows Server 2025 image, which ships the ARM64
  VC tools — Microsoft.VisualStudio.Component.VC.Tools.ARM64 @ 17.14 (= VS2022 toolset). So our
  aarch64-pc-windows-msvc cross-link has what it needs and builds today.
• The break I was gating on — #14215 "v143 ARM64
  build tool missing" — is scoped to the separate "WS2025 + Visual Studio 2026" image, a distinct label
  (windows-2025-vs2026) that our workflow does not target.

Why a future regression can't ship a broken binary to users

Every irreversible publisher gates on the full build matrix: release.yml's publish (crates.io,
needs: [check, build, deb]), npm (:410, same gate), and release (:197). A missing target artifact
also fails loud (build↔npm set-equality pinned by npm/generate.test.mjs). So if the aarch64 leg ever
fails to build, the entire tag's publish is blocked — npm/crates keep serving the last-good version, and
users never receive a partial or broken install. Worst case is a delayed release, visible as a red tag CI.

Residual watch-item (not blocking)

Migration tracker #14017 is still open and will
migrate both windows-latest and windows-2025 to the VS2026 image. When that flip completes, watch
the first tagged release's aarch64-pc-windows-msvc job (release.yml doesn't run on PRs, so it's the only
unvalidated-until-tag surface). If it regresses, re-pin — note the only stable label that keeps the working
ARM64 image is windows-2022 (windows-2025 migrates too), or windows-2025-vs2026 once #14215 is closed.

Closing as resolved — the carry-item action (unpin) is done and the record now matches reality.