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

build-windows compiled and linked fine but died at bundling with only
"failed to run candle.exe". The real cause was neither .NET nor the
runner identity, both of which I chased first and was wrong about.

candle.exe and light.exe are 32-bit. A runner running as SYSTEM has
%LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\AppData\Local,
which is where Tauri caches the WiX toolset. WOW64 redirection sends any
32-bit process reading C:\Windows\System32 to C:\Windows\SysWOW64 — and
the WixTools directory exists only in the 64-bit view. So candle.exe
could not see its own directory, the CLR failed to start, and the
process exited 0x80131700, surfaced in the Application event log as
".NET Runtime version 4.0.30319.0 - This application could not be
started."

Proven rather than assumed: copying the identical toolset to C:\wixtest
and running it as the same SYSTEM identity exits 0, while the
systemprofile path exits 0x80131700. Test-Path confirms the WOW64 view
of that directory does not exist.

Pointing LOCALAPPDATA at a path outside System32 avoids redirection.
This fixes it for any runner running as a service or as SYSTEM, without
needing a stored user credential, and is a no-op where the runner
already runs as a normal user.

For the record, two earlier theories were wrong. .NET 3.5 was missing
and is now installed from the ISO payload, but candle targets .NET 4.x
(its config uses loadFromRemoteSources, a 4.0-only element) so that was
never the blocker. Adding explicit supportedRuntime entries changed
nothing. Both are documented here so the next person does not repeat
them.

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