ci: build Windows ARM64 with Visual Studio 2026

[leehack]

Fixes the two Windows ARM64 failures in the scheduled v0.5.0 release run 35976011426 (build-windows (arm64, …, blas) and (arm64, …, vulkan)). The cause is the runner image, not v0.5.0.

Cause

Both jobs fail at configure:

CMake Error at CMakeLists.txt:2 (project):
  Generator

    Visual Studio 17 2022

  could not find any instance of Visual Studio.

Runner image for the same two jobs:

run	commit	upstream	image	VisualStudioVersion	result
35850331498 (09-23)	14d4f0b	v0.4.1	windows-11-arm64 20260914/20260920	17.0	pass
35976011426 (09-24)	14d4f0b	v0.5.0	windows-11-vs2026-arm64 20260914.159.1/20260920.164.1	18.0	fail

The native commit is the same in both runs. Only the image behind windows-11-arm changed: actions/runner-images#14602 moves that label to the VS 2026 image, rolling out from 2026-09-21 to 2026-09-30. That image has only VS 18. CMakePresets.json hardcoded "generator": "Visual Studio 17 2022" for windows-arm64-full. No other job changed image between the two runs.

Change

• windows-arm64-full generator: Visual Studio 18 2026. The architecture (ARM64) and the toolset name (ClangCL) are unchanged, but the compiler behind them moves from Clang 19.1.5 / MSVC 14.4x (VS 2022 image) to Clang 22.1.3 / MSVC 14.51 (VS 2026 image). The move comes with the image and happens whether or not this PR merges. Windows ARM64 has no ISA audit comparable to Android's. The only compiled evidence is the wrapper ctest in windows-arm64-kleidiai; Kleidi selector/compute qualification runs in the Linux QEMU lane.
• The arm64 jobs in native_release.yml and the windows-arm64-kleidiai lane in validate_wrapper.yml now run on windows-11-vs2026-arm. That is the image the plain label is moving to, but the explicit label cannot flip back and forth during the rollout. After Sep 30 both labels resolve to the same image.
• docs/platform_backend_strategy.md records the requirement. tools/build.py windows --arch arm64 now needs VS 2026. VS 2022-only users can configure directly with cmake --preset windows-arm64-full -G "Visual Studio 17 2022" in a fresh build dir. Verified locally that a command-line -G overrides a preset's generator (CMake 4.4.3). The presets file still declares cmakeMinimumRequired 3.23, so older CMake fails with a generator error rather than a version message.
• windows-11-vs2026-arm is the label #14602 offers for testing. After the rollout ends (Sep 30) both labels resolve to the same image, so a later switch back to windows-11-arm is optional.

The image readme lists everything the arm64 lanes use: VC.Llvm.ClangToolset, VC.Tools.ARM64, VC.Tools.x86.x64 (for the host-x64 vulkan-shaders-gen toolchain in cmake/windows-host-x64-toolchain.cmake), Windows SDK 26100, vcpkg, and CMake 4.4.3. The Visual Studio 18 2026 generator needs CMake 4.2 or later.

cmake/kleidiai_windows.cmake matches ^Visual Studio and is unaffected. The fixture's simulated Visual Studio 17 2022 generator string only exercises that match, so it is left as is.

Validation

• validate_wrapper → windows-arm64-kleidiai (pinned and post-v0.4.0) configures this preset on the VS 2026 image. It builds with ClangCL and the Kleidi ARMASM customization and runs the wrapper ctest contracts.
• python3 -m unittest discover -s tests: 157 tests OK.

Not covered by PR CI

native_release.yml runs only on dispatch, so the following are first exercised on VS 2026 by the next release dispatch:

• Vulkan arm64: the x64 Vulkan SDK installer, and the host-x64 vulkan-shaders-gen build through cmake/windows-host-x64-toolchain.cmake. That toolchain resolves VCToolsInstallDir, so it follows VS 18.
• BLAS arm64: the vcpkg cache vcpkg-Windows-arm64-windows-v1 (built on the VS 2022 image) is restored, and failed job 107556830067 logged OpenBLAS already present in cache. The release will therefore ship the VS 2022-built OpenBLAS DLL, which is ABI-compatible. vcpkg's OpenBLAS build on VS 2026 stays untested until that cache is evicted or VCPKG_CACHE_VERSION is bumped.
• Exact v0.5.0 on Windows ARM64: the release run stopped at configure, and this PR's lanes build the pinned v0.4.1 and the post-v0.4.0 candidate. An exact v0.5.0 windows-arm64-kleidiai row is added in the stacked v0.5.0 qualification PR, Qualify v0.5.0 Android CPU dispatch and source policy #93.

Independent review

A fresh reviewer re-derived the cause from both runs' logs and the image changelog. It confirmed the hosted lane ran on windows-11-vs2026-arm64 with ClangCL 22.1.3 and passed ctest 4/4. It found no blockers. Its disclosure points (compiler jump, build.py fallback, vcpkg cache, v0.5.0 coverage) are addressed above.