dotfiles: take the native arm64 rsync now that one is published

dotfiles: take the native arm64 rsync now that one is published

nuket/rsync-windows publishes an arm64 asset as of v3.5.0-gdeeda96f, so
ARM64 stops taking the x64 zip under emulation.

The rsync.exe was never the problem - a transfer is bounded by the
socket, not by emulated CPU. The ssh.exe beside it was: it links against
System32\libcrypto.dll, which on ARM64 is an ARM64 binary an x64 process
cannot load, so it died with 0xC0000135 (STATUS_DLL_NOT_FOUND) and the
verification step deleted it on every single run. Both binaries in the
arm64 zip are 0xAA64, and its ssh.exe reports

    OpenSSH_for_Windows_10.0p2 Win32-OpenSSH-GitHub, LibreSSL 3.8.2

so the fast client survives the run now instead of being thrown away.
Checked the published .sha256 against the download the way the script
does; it matches.

Keep the run-it-to-verify check on every architecture. It is cheap, it
is what found the mismatch in the first place, and it still covers a
missing or too-old libcrypto.dll anywhere.

Drop rsync from the audit's accepted-emulation table and give it a
remedy instead: an x64 rsync.exe on an ARM64 box is now a leftover from
a run before this asset existed, not an exception to tolerate, so it
should warn and say to re-run the elevated half.

Also correct a stale README bullet claiming NASM is still installed on
ARM64 - it went into the x64-only set with the rest.

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