CI: keep the WiX toolset out of System32 so 32-bit candle.exe can run

WiX's candle.exe/light.exe are 32-bit. A SYSTEM-run runner has
%LOCALAPPDATA% under C:\Windows\system32\config\systemprofile, where
Tauri caches the WiX toolset — and WOW64 redirection sends 32-bit
processes reading System32 to SysWOW64, which has no such directory. The
CLR then fails to start with 0x80131700 and Tauri reports only "failed
to run candle.exe".

Verified: the same binary and identity exits 0 from C:\wixtest and
0x80131700 from the systemprofile path.

Pointing LOCALAPPDATA outside System32 avoids redirection, needs no
stored credential, and is a no-op for runners already running as a
normal user.

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

.gitea/workflows/build-app.yml

@@ -339,6 +339,22 @@ jobs:
   build-windows:
     runs-on: windows-latest
     needs: [compute-version]
+    env:
+      # WiX 3.x candle.exe/light.exe are 32-bit. A runner running as SYSTEM has
+      # %LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\AppData\Local,
+      # and Tauri caches the WiX toolset there. WOW64 redirection then sends a
+      # 32-bit process reading C:\Windows\System32 to C:\Windows\SysWOW64, where
+      # that directory does not exist - so candle.exe cannot see its own folder,
+      # the CLR fails to start, and Tauri reports only "failed to run
+      # candle.exe". The real error is 0x80131700, visible in the Application
+      # event log as ".NET Runtime ... could not be started".
+      #
+      # Verified on our runner: candle.exe -? exits 0 from C:\wixtest and
+      # 0x80131700 from the systemprofile path - same identity, same binary.
+      #
+      # Pointing LOCALAPPDATA outside System32 sidesteps redirection entirely,
+      # and is harmless on a runner that already runs as a normal user.
+      LOCALAPPDATA: C:\actions-runner-cache
     defaults:
       run:
         shell: cmd