ifcviewer-wgpu: pick the Windows ARM64 wgpu-native archive when targeting ARM64

The Windows branch of the wgpu-native FetchContent block was
hardcoding the x86_64 archive name regardless of host arch — the
macOS and Linux branches already switch on
\`CMAKE_SYSTEM_PROCESSOR MATCHES "arm64|aarch64"\`, but Windows
didn't get the same treatment because the wgpu work was done on
x86_64 hosts.

Result on \`windows-11-arm\`: CMake downloaded
\`wgpu-windows-x86_64-msvc-release.zip\`, IfcViewerWgpu linked against
the x86_64 import library, and the final link of
IfcViewerWgpuMinimal/BonsaiViewer emitted ~60 unresolved \`wgpu*\`
externs because the import-lib symbols are x86_64-only.

Upstream wgpu-native v29.0.0.0 already publishes
\`wgpu-windows-aarch64-msvc-release.zip\` — switching on
\`CMAKE_SYSTEM_PROCESSOR\` so the right archive gets fetched is
sufficient.

Also restores the ARM64 row in \`.github/workflows/build_win.yml\`
that the prior commit dropped (the comment there was wrong; upstream
does ship the binary, our CMake just wasn't asking for it).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

.github/workflows/build_win.yml

@@ -16,11 +16,12 @@ jobs:
             build_branch: windows-x64
             zip_suffix: win64
 
-          # ARM64 dropped while BonsaiViewer is on: wgpu-native does not
-          # ship a Windows-ARM64 binary, so IfcViewerWgpu's link step fails
-          # with ~60 unresolved wgpu* externs. Re-enable when upstream
-          # publishes that target (or when we add ARM64 to the wgpu-native
-          # FetchContent URL allowlist).
+          - arch: ARM64
+            runs_on: windows-11-arm
+            deps_dir: _deps-vs2022-ARM64-installed
+            vcvars: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsarm64.bat"'
+            build_branch: windows-arm64
+            zip_suffix: win-arm64
 
     runs-on: ${{ matrix.runs_on }}