fix: link Windows ARM64 Vulkan against the native ARM64 Vulkan SDK

[leehack]

Fixes the one failure in the v0.5.0 release retry 36004579792: build-windows (arm64, …, vulkan). All other finished build jobs passed: all four Android jobs, Windows arm64 blas, Linux, Apple, and smoke-release-contract. Windows x64 CUDA was still running when this PR was opened.

Cause

lld-link : error : vulkan-1.lib(vulkan-1.dll): machine type x64 conflicts with arm64
  [...\build\wa64\third_party\llama.cpp\ggml\src\ggml-vulkan\ggml-vulkan.vcxproj]

The arm64 lane installed LunarG's x64 SDK (vulkansdk-windows-X64-1.4.313.2.exe), and tools/build.py passes no Vulkan_LIBRARY on arm64. FindVulkan therefore picked C:/VulkanSDK/1.4.313.2/Lib/vulkan-1.lib, an x64 import library.

The passing VS 2022 run 35850331498 found the same library (-- Found Vulkan: C:/VulkanSDK/1.4.313.2/Lib/vulkan-1.lib) and linked it. Both runs linked with ClangCL's lld-link against that same x64 library. What changed with the image is the LLVM version: Clang 19.1.5 on windows-11-arm64, Clang 22.1.3 on windows-11-vs2026-arm64. The newer lld-link rejects the x64 import objects that 19.1.5 accepted. #91 flagged this lane as "first exercised by the next release dispatch", and this is what that dispatch hit. The cause is neither upstream v0.5.0 nor the other fixes.

Change

• New composite action .github/actions/install-vulkan-sdk-windows (arch: x64|arm64):
  • arm64 installs LunarG's native ARM64 SDK at the same pinned version, filed under their warm platform: https://sdk.lunarg.com/sdk/download/1.4.313.2/warm/vulkansdk-windows-ARM64-1.4.313.2.exe.
  • x64 keeps the same installer and version as today.
  • Each installer's SHA-256 is checked against LunarG's published index (https://vulkan.lunarg.com/sdk/files.json). Before this, the download wasn't checked at all.
  • It fails if Lib/vulkan-1.lib isn't built for the target machine (dumpbin /headers), so a wrong-architecture SDK can't reach the linker again.
• native_release.yml Windows lanes use the action for both architectures.
• validate_wrapper.yml: new windows-arm64-vulkan lane (pinned, v0.5.0) on windows-11-vs2026-arm. It runs the release command python tools/build.py windows --arch arm64 --backend vulkan and checks that ggml-vulkan.dll is ARM64 and imports vulkan-1.dll. PR CI never built this lane before, which is why the problem only showed up in the release. It is wired into the wrapper-validation aggregate and tools/ci_scope.py.
• tests/test_windows_vulkan_sdk.py checks the action's URLs and digests, and that both workflows use it. There's also a doc note in docs/platform_backend_strategy.md.

Validation

• python3 -m unittest discover -s tests: 161 tests OK.
• actionlint: the only findings are the known stale windows-11-vs2026-arm label and pre-existing shellcheck notes on PowerShell steps.
• Hosted: windows-arm64-vulkan (pinned) and (v0.5.0), results to follow.

Note on previously published arm64 Vulkan artifacts

v0.4.1 and v0.4.1-1 ggml-vulkan.dll for Windows arm64 were linked by the VS 2022 toolchain against this x64 import library. I haven't determined whether that produced correct ARM64 import thunks. The new lane's dumpbin checks apply only to builds from now on. Testing an existing artifact on real Windows-on-ARM hardware would settle it.

Independent review

A fresh reviewer independently confirmed:

• both installer URLs, and that the digests and sizes match LunarG's files.json (HEAD requests only, nothing downloaded);
• the PowerShell logic, including that the \($machine\) pattern matches dumpbin's import-library output but not (ARM64EC);
• dumpbin is on PATH in both callers;
• the ARM64 SDK's glslc reports the same 11 shader feature lines as the x64 SDK;
• the new lane mirrors the release job's relevant steps, and ci_scope treats edits to the new action as native changes.

It found no blockers, and all 25 hosted checks pass, including windows-arm64-vulkan (pinned) and (v0.5.0).

Its process note: do not re-run the failed job in 36004579792. A re-run uses that run's commit 6f2cb11, which still installs the x64 SDK. Dispatch a fresh release from main after this merges.

Its other notes, none blocking:

• PR CI never exercises the x64 path of the action; the next release is its first use. There the only change is the added checksum and machine checks.
• The published v0.4.1 / v0.4.1-1 arm64 DLLs are probably correct, because lld builds import thunks for the output machine. They can be checked on a windows-11-arm runner, without a GPU, using dumpbin /imports and LoadLibrary.