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>

.gitea/workflows/build-app.yml

@@ -612,7 +612,11 @@ jobs:
       - name: Install Tauri CLI via cargo
         run: |
           set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%"
-          cargo install tauri-cli --version "^2"
+          rem Pinned to the @tauri-apps/cli version in app/package-lock.json, which
+          rem the Linux and macOS jobs run: the Windows code-signing path (sign
+          rem command, NSIS uninstaller signing) was verified against it, and "^2"
+          rem would change it underneath the pipeline on any Tauri release.
+          cargo install tauri-cli --version "=2.11.0" --locked
 
       - name: Fix npm platform detection
         run: |
@@ -635,8 +639,8 @@ jobs:
 
       # Releases are signed with Azure Artifact Signing (scripts/windows-*.ps1).
       # The setup fetches the signing client and a job-local .NET runtime, and
-      # exports TAURI_CONFIG with the sign command - which is why "Build Tauri
-      # app" no longer sets it. A missing secret fails here, before the build.
+      # writes the Tauri config holding the sign command, which "Build Tauri
+      # app" passes with --config. A missing secret fails here, before the build.
       - name: Prepare code signing
         env:
           AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
@@ -649,9 +653,10 @@ jobs:
 
       - name: Build Tauri app
         working-directory: ./app
-        # No TAURI_CONFIG here: "Prepare code signing" exports it with the sign
-        # command, and a step-level value would override it and silently drop
-        # signing.
+        # The sign command comes in through --config, from the file "Prepare
+        # code signing" wrote. Not TAURI_CONFIG: the v2 CLI never reads that
+        # variable (the inline one this step used to set was a no-op), and
+        # "Verify signatures" is what caught it.
         env:
           # Read by the signing dlib itself, never passed on a command line.
           AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
@@ -671,7 +676,7 @@ jobs:
           rem systemprofile\AppData\Local\tauri and systemprofile\.cache to the
           rem System32 originals, which makes the redirected view resolve. A
           rem runner running as a normal user needs no such patch.
-          cargo tauri build --bundles msi,nsis
+          cargo tauri build --bundles msi,nsis --config "%TRIPLE_C_TAURI_SIGN_CONFIG%"
 
       - name: Verify signatures
         run: >-