Migrate Windows arm64 release build to native windows-11-arm runner

[warp-agent-staging]

Warning

This PR currently carries a temporary test-only commit that must be removed before merge: TEMPORARY TEST SCAFFOLDING: isolate Windows arm64 in create_release.yml (commit 8a9c508). It restricts a manual workflow_dispatch run to the Windows arm64 path only, so the migration can be tested without running the full release matrix. Drop that one commit (a single, self-contained revert/rebase) before merging. See "Temporary test-only commit" below for exactly what it does.

Summary

Migrates the Windows arm64 release build (both the main app and the TUI) from x86_64 cross-compilation to native compilation on the windows-11-arm GitHub-hosted runner. The Windows 11 Arm64 GA runner image now ships the same VC++/Windows SDK/LLVM toolchain as the x64 image, so cross-compilation is no longer necessary. Stacked on #13240.

Changes

• build_windows_binaries / release_windows: changed the arm64 leg's matrix.runner from windows-latest-large to windows-11-arm (the x64 leg is untouched).
• build_windows_tui_binaries / release_windows_tui: gave these jobs the same per-arch matrix.runner treatment (they previously had a flat runs-on: windows-latest-large), pointing the arm64 leg at windows-11-arm.
• Dropped the Add arm64 target (rustup target add aarch64-pc-windows-msvc) steps in the two build jobs, since the arm64 leg's host target is now aarch64-pc-windows-msvc rather than a cross-compiled add-on.
• Disabled azure/artifact-signing-action's dependency cache (cache-dependencies: false) in both signing steps. That cache is not keyed by runner architecture, so the x64 and arm64 legs of the matrix can corrupt each other's cached tools when they sign concurrently (Azure/artifact-signing-action#146).
• script/install_cargo_binstall: pinned the aarch64-pc-windows-msvc cargo-binstall archive and its verified SHA-256 alongside the existing x86_64 entry, and fixed archive_for_platform's Windows arch detection to read PROCESSOR_ARCHITEW6432/PROCESSOR_ARCHITECTURE instead of uname -m (Git for Windows' MSYS runtime doesn't report the true host architecture there, so the aarch64 entry was otherwise unreachable).

Temporary test-only commit

The final commit on this branch, TEMPORARY TEST SCAFFOLDING: isolate Windows arm64 in create_release.yml, is scaffolding for manually testing this migration, requested for after code review passes. It is not part of the migration itself and must be dropped before merge. It:

• Flips the default of the build_linux, build_macos, and build_web workflow_dispatch inputs to false (the workflow_call inputs used by real automated releases are untouched). collect_results derives which platforms are "disabled" from these same inputs, so a default manual test run correctly excludes those platforms from its pass/fail rollup instead of reporting a spurious failure.
• Isolates the arm64 leg of build_windows_tui_binaries, release_windows_tui, and release_windows by commenting out the x64 entry in each job's matrix.include (not via a job-level if:, since jobs.<job_id>.if cannot see the matrix context).
• Leaves build_windows_binaries running both legs unchanged, since its x64 leg alone produces the canonical Windows settings schema artifact the arm64 release jobs depend on.

A manual workflow_dispatch run of create_release.yml (with channel and build_windows: true, leaving build_linux/build_macos/build_web at their default) will therefore exercise only: prepare_release → build_windows_binaries (both legs) → build_windows_tui_binaries (arm64 only) → release_windows (arm64 only) and release_windows_tui (arm64 only) → collect_results. Every other release job is skipped and correctly excluded from collect_results' pass/fail rollup.

Verification

This can only be fully verified by actually running the workflow on windows-11-arm, which I can't do from here. What I checked instead:

• The workflow YAML parses and every job's if:, matrix.include, and the workflow_dispatch/workflow_call input defaults resolve as expected (verified with js-yaml), including confirming no job-level if: references the matrix context (cross-checked against GitHub's documented context availability table, which lists only github, needs, vars, inputs for jobs.<job_id>.if) and that the workflow_call input defaults are untouched.
• script/install_cargo_binstall's new SHA-256 for cargo-binstall-aarch64-pc-windows-msvc.zip was independently verified by downloading the v1.18.1 asset and computing its digest locally.
• The PROCESSOR_ARCHITEW6432/PROCESSOR_ARCHITECTURE dispatch logic was sanity-checked in isolation under bash -u for all three relevant cases: an unemulated x64 host (unchanged from before), an arm64 host running x64-emulated Git Bash, and an arm64 host running native arm64 Git Bash.
• script/windows/build_inno_sign_tool_command.ps1 needs no change: the Windows SDK installs x86, x64, arm, and arm64 signtool.exe subfolders side-by-side on every host regardless of its own architecture, and Azure's Trusted Signing dlib has no arm64 build at all, so the script's existing x64 filters remain correct — an arm64 signtool.exe can't load the x64-only dlib anyway.
• protoc install (choco + winget fallback in prepare_environment) needs no change either: neither package publishes an arm64 Windows archive, but the x64 archive runs fine under Windows 11 arm64's built-in x64 emulation, which only affects toolchain install speed, not the codegen it produces.
• azure/artifact-signing-action officially does not support Windows arm64 runners, but multiple public reports confirm it works via x64 emulation as long as its dependency cache is disabled when x64 and arm64 legs of a matrix run concurrently — hence the cache-dependencies: false addition above. This, and whether the arm64 build genuinely succeeds end-to-end, remain the parts of this change that only an actual run on windows-11-arm can confirm.

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.