Publish native ARM64 Windows binary

[backnotprop]

Background

Today the release pipeline builds only bun-windows-x64 for Windows (release.yml line 88). ARM64 Windows users — Surface Pro X, Copilot+ PCs, Azure ARM VMs — run the x64 binary via Windows 11's x86-64 emulation layer.

Until PR #512, this worked inconsistently across the two Windows installer paths:

• install.cmd hardcoded PLATFORM=win32-x64, so ARM64 users silently received the x64 binary and ran it under emulation. Worked, accidentally.
• install.ps1 correctly detected ARM64 and tried to download plannotator-win32-arm64.exe — a file we don't publish. 404, install aborted, stack trace.

PR #512 fixed the symptom in install.ps1 by making it match install.cmd's behavior (always fall back to x64, print a notice when ARM64 is detected). Both installer paths now produce a working install on ARM64 Windows, but both are serving the emulated x64 binary.

What this issue tracks

Publishing a native ARM64 Windows binary so ARM64 users get native-speed performance instead of the emulation tax.

Approach

1. Verify Bun supports the target. Run bun build --help or check Bun's release notes for --target=bun-windows-arm64. Confirm the target is stable and produces working binaries.
2. Add the target to release.yml. Mirror the existing bun-windows-x64 block:

   bun build apps/hook/server/index.ts --compile --target=bun-windows-arm64 --outfile plannotator-win32-arm64.exe
   sha256sum plannotator-win32-arm64.exe > plannotator-win32-arm64.exe.sha256

   Same for plannotator-paste-*.
3. Add to the attestation step. The actions/attest-build-provenance step lists subject paths explicitly — add the two new ARM64 binaries.
4. Revert the install.ps1 fallback. Change $arch = "x64" back to the conditional form (if ARM64 { "arm64" } else { "x64" }). install.cmd needs the same restoration to differentiate — set PLATFORM based on PROCESSOR_ARCHITECTURE.
5. Update CI. The Windows integration test job currently runs on windows-latest which is x64. Consider adding a windows-11-arm runner to the matrix so the ARM64 install path is actually exercised end-to-end.

Blockers / unknowns

• Bun's Windows ARM64 target maturity. If bun-windows-arm64 produces broken binaries or isn't supported, this is blocked until Bun ships it.
• windows-11-arm runner availability in GitHub Actions. At the time of writing, ARM64 Windows runners exist but may be preview / paid-only.

Impact

Population of affected users is small (ARM64 Windows is a minority slice of Windows users) but growing as Copilot+ PCs and ARM-based Azure VMs proliferate. Native binaries would eliminate the emulation performance tax (rough rule of thumb: 15-25% slower on emulated x64 vs native ARM64) and avoid any emulator-specific compatibility bugs that might appear over time.

Related

• PR Supply-chain hardening: version pinning, SLSA attestations, fix #506 #512 — shipped the fallback fix in install.ps1 and install.cmd
• Review cycle 7 finding that surfaced the underlying gap