feat(windows): native ARM64 build (prebuilt PDFium/WebView2Loader + experimental workflow)

[art804]

Adds native Windows-on-ARM support: prebuilt ARM64 dependencies plus an
experimental, manually-triggered CI workflow that produces an arm64 NSIS
installer on GitHub's windows-11-arm runners (free for public repos).

binaries/win-arm64/

• pdfium.dll — bblanchon chromium/7834, the same PDFium release the
  existing win-x64 dll and the Linux CI fetch already pin.
• WebView2Loader.dll — Microsoft.Web.WebView2 1.0.4078.44,
  runtimes/win-arm64/native.
• README.md documents provenance/update steps, matching the win-x64 dir.

.github/workflows/windows-arm64.yml (experimental, workflow_dispatch)

• Swaps bundle.resources to the win-arm64 pdfium/WebView2Loader, then builds
  through the normal tauri:build path — build.rs already suffixes the
  pdfium-worker sidecar with the host target triple
  (aarch64-pc-windows-msvc), so no manual sidecar copy is needed.
• Verifies the built exe's PE machine type is ARM64 and uploads the installer.

Kept standalone and manual on purpose, so it can be stabilised before being
folded into the release matrix. Remaining integration steps for release.yml
(left out of this PR to keep it focused): a per-user installer variant,
Authenticode signing, and windows-aarch64 entries in the updater's
latest.json.

Verified: produces a working native arm64 installer on windows-11-arm.

[art804]

Rebased onto main (1.79.0) and fixed an arm64 packaging bug I hit while testing this on real hardware.

Since #293 moved the Windows bundled DLLs (pdfium.dll, WebView2Loader.dll) into tauri.windows.conf.json, the arm64 resource swap had to move there too. As a platform override it's merged over tauri.conf.json, so rewriting bundle.resources in the base config is silently undone — the arm64 installer ends up shipping the x64 pdfium.dll. init_pdfium then can't load the wrong-arch DLL, PDFium stays uninitialised, and every page renders blank (the UI still loads, which makes it easy to miss). The swap now targets tauri.windows.conf.json and replaces the resources object so the x64 key is dropped.

I also added a check to the verify step that fails the build if the bundled pdfium.dll isn't ARM64 — the existing check only inspected the main exe, which passes while rendering is silently dead.

Verified: a native ARM64 build now opens and renders PDFs correctly on a Windows-on-ARM device. Happy to adjust anything.

[art804]

A note on the red check here, in case it's what's holding this up.

build (ubuntu-22.04) fails at Test AppImage smoke checks:

AppImage startup smoke passed
smoke unexpectedly accepted a GVFS symbol failure

That's the Linux AppImage harness's own GVFS negative case. This PR is Windows-only: two prebuilt DLLs under open-pdf-studio/src-tauri/binaries/win-arm64/, a README and licence note, and a workflow_dispatch-only workflow. Five files, additions only, no changes to any existing build or release path. build (windows-latest), build (macos-26) and render-regression are all green.

Happy to rebase onto 1.84 for a fresh CI run whenever suits. I've held off because main's own CI is red at the moment, and that one looks like a small metadata slip rather than anything real:

test:quality → release metadata is versie-consistent met package.json reads open-pdf-studio/src-tauri/Cargo.lock, which still says version = "1.82.0", and compares it against package.json at 1.84.0. The workspace root Cargo.lock was bumped correctly, so it's only the nested lock that's stale. Since open-pdf-studio/src-tauri is a workspace member, cargo resolves against the root lock and ignores the nested one, so bumping that single line (or dropping the nested lock entirely) should put main back to green without affecting builds.

Glad to send that as its own small PR if it would save you a minute. And happy to make any changes you'd like here in the meantime.