dotfiles: split provisioning between x64 and ARM64

dotfiles: split provisioning between x64 and ARM64

The ARM64 machine is a small VM, and nearly everything it installed
without a native build ran under Prism emulation. Each exception was
defensible on its own; together they were a VM full of x64 binaries.

So the two architectures now provision different things on purpose. x64
is the full workstation. ARM64 gets MSVC and nothing that duplicates it
or exists only as an x64 binary: Brave, WinMerge, upstream LLVM, NASM,
Android GPU Inspector, OpenCppCoverage, BinSkim, Visual Studio's
clang-cl, and the WDK are all dropped there. :x64only in the batch file
is the single place the policy is applied, so every skip prints its
reason into the run log instead of leaving a silent gap.

Two of those are dropped by choice rather than limitation, and the
comments say so: a native ARM64 clang-cl is offered on Arm and worked
here before this change.

The WDK could not have installed anyway, which is worth recording. It
requires the matching Windows SDK revision, and revisions are not
side-by-side - Include\10.0.26100.0 is one directory whichever wrote it.
VS 2026 installs SDK 26100.7705; linkid=2335869 is WDK 26100.6584, the
kit paired with VS 2022. wdksetup.exe /quiet therefore aborts with exit
15605 and WER "WDK / 10.1.26100.6584 / Install / 0x80070642" - 0x642 is
1602, ERROR_INSTALL_USEREXIT, a silent install cancelling itself on a
failed prerequisite. Nothing to do with Arm; the same pairing fails on
x64.

Fix the architecture detection, which this change makes load-bearing.
Both sources the scripts trusted report the EMULATED architecture inside
an emulated x64 process - which is what `powershell` resolves to when
launched from an x64 shell on an ARM64 box. Measured there:

    [RuntimeInformation]::OSArchitecture      X64     wrong
    %PROCESSOR_ARCHITECTURE%                  AMD64   wrong
    HKLM\...\Session Manager\Environment      ARM64   right

OSArchitecture is documented as the OS's architecture, and on .NET Core
it is; under .NET Framework on Prism it is not. All three scripts now
read the registry and keep the old sources as a fallback. This was a
mislabelled log line before; now it decides which packages install at
all. The batch parses reg.exe without piping to find/findstr - both are
shadowable, and a POSIX find turns the detection into a silent no-op
that leaves the emulated answer standing.

Stop invoking `py`, which failed with "'py' is not recognized" for two
independent reasons that look identical at the prompt. The session
inherits its PATH before winget installs Python, so nothing winget adds
is visible - the same staleness the DOTNET_EXE lookup already handles.
And the launcher may not exist: on this box every other Python component
registered while no launcher did, and the Launcher directory is on the
user PATH but absent. Resolve an interpreter by full path instead,
preferring the launcher only when it is real, and require python.exe
inside the directory - a half-removed version leaves the folder behind
with only Doc and Lib, which is what this box has.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ak6VzfGyaocrykX1LhNMwt