fix(ci): pass the sign command with --config and prove the uninstaller was signed

The first signing run built nothing signed, and "Verify signatures" failed
it as intended. The Tauri 2 CLI never reads TAURI_CONFIG. It only sets that
variable for tauri-build, so the sign command was dropped silently, just as
the inline beforeBuildCommand override had been for as long as the Windows
jobs have set it. The setup now writes a config file, and the build passes
it with `cargo tauri build --config`.

Review follow-ups:
- The NSIS uninstaller is written to %TEMP% and signed from 32-bit makensis.
  SYSTEM's %TEMP% sits under System32, which WOW64 redirects for makensis but
  not for the x64 signtool, so they would disagree about where the file is.
  %TEMP% and %TMP% now point into the workspace. makensis ignores the sign
  command's exit code for the uninstaller, so windows-sign.ps1 logs every
  file it signs, and the verify step requires a logged signature under that
  temp directory.
- The signing client is pinned by SHA-512, so the pin can be checked against
  nuget.org's published packageHash.
- tauri-cli on Windows is pinned to =2.11.0 --locked, the @tauri-apps/cli
  version the Linux and macOS jobs run from the lockfile, instead of "^2".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -845,8 +845,9 @@ unsigned or untimestamped, so an unsigned installer cannot ship quietly.
 
 - `scripts/windows-signing-setup.ps1` runs once per job. It downloads the signing client
   (`Microsoft.ArtifactSigning.Client`) and a .NET runtime into `.code-signing/` in the workspace,
-  **each pinned by version and hash**, writes the dlib's `metadata.json`, and exports
-  `TAURI_CONFIG` with `bundle.windows.signCommand`. Nothing is installed on the build VM. To bump
+  **each pinned by version and hash**, writes the dlib's `metadata.json`, and writes a Tauri
+  config file with `bundle.windows.signCommand` that the build passes as
+  `cargo tauri build --config`. Nothing is installed on the build VM. To bump
   a pin, take the hash from nuget.org / the .NET `releases.json`, never from your own download.
 - `scripts/windows-sign.ps1` is the sign command: `signtool sign /dlib` with SHA-256 and the
   Microsoft timestamp server, retried. Credentials never reach a command line — the dlib reads
@@ -859,14 +860,17 @@ Secrets (repository): the three `AZURE_*` above plus `ARTIFACT_SIGNING_ENDPOINT`
 - **`metadata.json` excludes every credential but `EnvironmentCredential`.** The dlib uses
   `DefaultAzureCredential`, whose chain ends in `InteractiveBrowserCredential`; the runners run as
   SYSTEM, where that waits forever for a browser.
-- **The "Build Tauri app" steps must not set `TAURI_CONFIG`.** A step-level value overrides the
-  one the setup exported and drops the sign command without an error — "Verify signatures" is
-  what would catch it.
-- **The signing files live in the workspace, not `%TEMP%`.** The NSIS uninstaller is signed from
-  inside 32-bit `makensis`, which runs the sign command under 32-bit PowerShell; WOW64 redirects
-  SYSTEM's `%TEMP%` (under System32) for that process. The workspace is under
-  `systemprofile\.cache`, which the VM junctions for exactly this (see the comment on
-  `build-app.yml`'s "Build Tauri app").
+- **The sign command goes in through `--config`, never `TAURI_CONFIG`.** The v2 CLI does not read
+  that variable — it only sets it, for tauri-build — so a config put there is dropped without an
+  error. The Windows jobs set an inline `TAURI_CONFIG` for years and it never applied;
+  "Verify signatures" is what exposed it, and it is what would catch a regression.
+- **The signing files and the job's `%TEMP%` live in the workspace.** The NSIS uninstaller is
+  written to `%TEMP%` and signed from inside 32-bit `makensis`, under 32-bit PowerShell; WOW64
+  redirects SYSTEM's own `%TEMP%` (under System32) for those processes but not for the x64
+  signtool, so they would disagree about where the file is. The workspace is under
+  `systemprofile\.cache`, which the VM junctions so both views resolve. makensis also ignores
+  the sign command's exit code for the uninstaller, so `windows-sign.ps1` logs every file it
+  signs and the verify step requires a logged signature under that temp directory.
 - **The build VM is `WindowsBuilder` (VM 110 on the Proxmox host `pve4`)**, carrying both the
   `winvm-builder` and `virtual-builder` runners in host mode. It has the Windows SDK's
   `signtool` (10.0.26100) but no .NET — hence the job-local runtime.