Stop reporting an unknown Windows architecture as unsupported

[leoafarias]

What this changes

tool/install.ps1 compared the .NET architecture probe straight to 'X64', so a session where the probe returned nothing and a real Arm64 machine produced the identical throw: Only Windows x64 has a prebuilt Wayfinder bundle. The reporter was on Windows x64 — an interactive Windows PowerShell 5.1 session returned nothing from [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture, and the installer answered by naming the one thing that was not wrong with their machine. The same command worked under -NoProfile.

Architecture detection follows the established convention. The probe is wrapped in try/catch, as cargo-dist's generated installer.ps1 does (the API is absent before .NET 4.7.1); an empty result now means unknown, not unsupported. It falls back to the environment the way dotnet-install.ps1 does, preferring the machine scope, which reports the hardware even inside an emulated process where the process variable claims AMD64 on an Arm64 box. Nothing assumes an architecture, so the two failures read differently:

• indeterminate → says so, and prints the clean-session -NoProfile command;
• detected → Windows Arm64 has no prebuilt Wayfinder bundle; only Windows x64 has one.

Both installers now share one shape. The architecture and tar checks moved before any network call, and so did the WAYFINDER_SKILLS and WAYFINDER_INSTALL_ROOT checks, which sat after the latest-release lookup — so a typo in either cost a round trip before the installer said so. Machine, tools and caller input first, network second, matching install.sh, rustup and cargo-dist. Windows PowerShell 5 hosts get the TLS 1.2 idiom Deno, Scoop and Chocolatey use, gated on PS 5 because it outlives the caller's session — without it an older host fails the download with a transport error that says nothing. install.sh now names the machine it detected (Darwin-x86_64 has no prebuilt Wayfinder bundle; ...), for the same reason the Windows message does, and its two leftover single-item for name in wayfinder loops are flattened.

Tests follow the same split the reference installers use — run the real script on a real runner:

• New Installer scripts workflow, on every PR touching the installers. It parses install.ps1 under both pwsh and Windows PowerShell 5.1 and runs tool/test_install_arch.ps1; on Ubuntu it shellcheck-lints install.sh and runs tool/test_install_platform.sh. No release archive, no network, about a minute.
• tool/test_install_arch.ps1 — empty probe falls through to the environment (the Windows install script throws "Only Windows x64 has a prebuilt Wayfinder bundle" on genuine x64 machines when run in an interactive session #98 regression), AMD64 normalizes to x64, an Arm64 probe and an ARM64 machine environment are both refused by name, and nothing-to-go-on reports indeterminate.
• tool/test_install_platform.sh — unsupported machines are named, and both published platforms clear the gate.
• tool/verify_installer.ps1 — the Windows install script throws "Only Windows x64 has a prebuilt Wayfinder bundle" on genuine x64 machines when run in an interactive session #98 session end to end: an emptied probe installs the archive CI just built and indexes with it.

Both new test scripts substitute the detection call in a copy of the installer and assert every substitution matched, so they fail loudly instead of passing vacuously if the installer is rewritten. Each case stops at a check that precedes the first download; cases that must clear the gate set an unusable WAYFINDER_VERSION and expect its rejection as proof. A .NET static property cannot be shadowed the way verify_installer.ps1 shadows Invoke-WebRequest, which is why the substitution approach exists at all.

Also removed: tool/ci/verify-installer.sh — unreferenced, and it asserted OKF_VERSION pins and okf/okfp binaries that install.sh stopped having at the rename, so it would fail on its first line if anything ran it. Say the word if you would rather keep it.

Linked issue

Closes #98

If this changes the profile

Not applicable — no profile change.

If this changes a rule the skills restate

Not applicable — no rule change. The installer URLs and messages the docs quote were updated in docs/install.md.

Checks

• Dart format, analysis, tests, and the shipped wayfinder validate example gate pass — not run: no Dart, pubspec or example changed. CI runs them here regardless.
• Nothing added that names a client, a domain, or a project's own vocabulary
• Precedence respected: OKF over the profile, the profile over the implementation guide — nothing in either layer changed
• Scope not widened beyond the issue — widened deliberately, by request: the issue is the Windows message, and the ask was to review both installers for convention, add Windows CI coverage, and clean up. The convention fixes, the new workflow and the dead-script removal are that. The architecture fix stands alone if you would rather split it.

Verification

Locally: sh tool/test_install_platform.sh passes, shellcheck --shell=sh and sh -n are clean on both POSIX scripts, actionlint is clean on all workflows, and tool/ci/verify-installer-pins.sh passes. There is no PowerShell on this machine, so the Windows jobs in this PR are the first execution — and first syntax check — of the PowerShell changes. That gap is exactly what the new workflow closes going forward; I am watching the run and will push fixes if it trips.

An open question for the reporter, which the fix does not depend on: running the diagnostic snippet from the issue thread would confirm why their session's probe came back empty.