feat(release): native windows/arm64 binary and PyPI wheel

[wesm]

Adds a native windows/arm64 build to the release pipeline, so Windows-on-ARM users get a real ARM64 binary instead of nothing (the installer currently 404s on arm64 because no asset is published).

What changed

release.yml -- new windows/arm64 matrix entry on a native windows-11-arm runner:

• cgo (mattn/go-sqlite3 + fts5) needs a C compiler. Set up a self-contained llvm-mingw aarch64 toolchain (clang + mingw runtime + lld) -- no Visual Studio / Windows SDK required -- and point CC at it.
• Because the build runs on real ARM hardware, the existing ./agentsview --version smoke test executes natively (the GOARCH == GOHOSTARCH guard passes).
• The existing amd64 MinGW step is scoped to amd64; packaging continues to use 7-Zip (preinstalled on the arm64 image).

build_wheels.py -- add windows_arm64 -> win_arm64 to PLATFORM_MAP, so a native win_arm64 PyPI wheel is published and pip install agentsview works on Windows on ARM. --require-all now expects this artifact, which the new matrix entry produces. Tests updated (46 passed).

Validation

The release.yml workflow only runs on tag push, so it cannot be exercised by PR CI. Instead I validated the exact recipe locally on Windows 11 arm64 hardware:

• frontend npm run build: ok
• CGO_ENABLED=1 GOARCH=arm64 CC=aarch64-w64-mingw32-clang go build -tags fts5: builds a native ARM64 PE (0xAA64) that runs (--version exits 0)
• build_wheels.py produces agentsview-<ver>-py3-none-win_arm64.whl containing the ARM64 binary
• release.yml parses as valid YAML

The runner image (Windows11-Arm64) was confirmed to include 7-Zip and Bash, which the workflow relies on.

Once this is released, the installer's arm64 path (PR #597) automatically prefers the native asset over the amd64-under-emulation fallback.

🤖 Generated with Claude Code

[roborev-ci]

roborev: Combined Review (2fd2c61)

Security review found 1 medium issue; no other findings reported.

Medium

• .github/workflows/release.yml:152 - The Windows arm64 release job downloads and extracts a third-party compiler toolchain from a GitHub release asset, adds it to PATH, and uses it for the release build without verifying a pinned checksum or signature. If the upstream asset is replaced or the upstream repository is compromised, the workflow could execute attacker-controlled compiler code and publish compromised binaries/wheels.

  Suggested remediation: pin and verify the archive digest before extraction, such as checking Get-FileHash against an expected SHA256 before running 7z, or verify an upstream signed checksum/signature from a trusted key.

---

Panel: ci_default_security | Synthesis: codex, 8s | Members: codex_default (codex/default, done, 2m23s), codex_security (codex/security, done, 51s) | Total: 3m22s

[roborev-ci]

roborev: Combined Review (4f1919c)

High-level verdict: one high-severity CI supply-chain risk needs remediation before merge.

High

• .github/workflows/release.yml:152: The new Windows ARM release path downloads a third-party compiler toolchain with Invoke-WebRequest and immediately extracts/executes it without verifying a checksum or signature. If the upstream GitHub release asset is replaced or the upstream project/account is compromised, the malicious toolchain could run during the release build and produce a trojaned windows_arm64 binary that is later published in the GitHub release and PyPI wheel.

  Suggested remediation: pin the downloaded archive by an expected SHA256 digest stored in the workflow or repository, verify it before extraction, and fail the job on mismatch. Prefer provenance/signature verification too if upstream provides it.

---

Panel: ci_default_security | Synthesis: codex, 10s | Members: codex_default (codex/default, done, 3m50s), codex_security (codex/security, done, 1m8s) | Total: 5m8s

[roborev-ci]

roborev: Combined Review (73d59d8)

No issues found.

---

Panel: ci_default_security | Synthesis: codex | Members: codex_default (codex/default, done, 2m33s), codex_security (codex/security, done, 50s) | Total: 3m23s