install.ps1 never selects the shipped Windows ARM64 asset

[wernerkasselman-au]

Summary

The release workflow builds officecli-win-arm64.exe, and the root README
lists it as the Windows ARM64 binary. The PowerShell installer cannot install
that asset because it pins the download name at startup:

$asset = "officecli-win-x64.exe"

There is no architecture branch after that assignment. Every PowerShell
installation therefore requests the x64 asset, including on Windows ARM64.

Evidence

install.ps1 currently starts with:

$repo = "iOfficeAI/OfficeCLI"
$asset = "officecli-win-x64.exe"
$binary = "officecli.exe"

The release matrix separately produces:

- rid: win-x64
  name: officecli-win-x64.exe
- rid: win-arm64
  name: officecli-win-arm64.exe

The root README also advertises both assets in its manual-download table.

Expected

On Windows ARM64, the installer should select:

officecli-win-arm64.exe

On Windows x64, it should retain:

officecli-win-x64.exe

Actual

The installer always downloads officecli-win-x64.exe.

This may be masked by x64 emulation on ARM64 machines, so the symptom is not
necessarily an installation failure. The concrete defect is that the native
ARM64 artifact is shipped and advertised but is unreachable through the
PowerShell installation path.

Verification

On a Windows ARM64 host, install from a clean path and compare the installed
officecli.exe hash with the release SHA256SUMS entry for
officecli-win-arm64.exe.

The installed file should match the ARM64 checksum, not the x64 checksum.

A source-level regression check can also assert that the asset resolver returns
officecli-win-arm64.exe for an ARM64 Windows architecture and
officecli-win-x64.exe for x64.

[goworm]

Fixed on main. install.ps1 now selects the asset by host architecture — it reads PROCESSOR_ARCHITEW6432/PROCESSOR_ARCHITECTURE and requests officecli-win-arm64.exe on ARM64, officecli-win-x64.exe otherwise. Thanks for the precise diagnosis.