CI: restore the MSI now that the 32-bit bundlers can resolve their paths

Dropping the MSI did not help, because the problem was never WiX.
makensis.exe is 32-bit exactly like candle.exe and light.exe, lives in
the same SYSTEM-profile cache, and failed the same way — "Unable to
start child process, error 0x2" instead of 0x80131700.

The cause is WOW64 redirection: a 32-bit process reading
C:\Windows\System32 is served C:\Windows\SysWOW64, where the toolset
directory does not exist, so the bundlers cannot see their own folder.

The build VM now carries two junctions from the SysWOW64 view of
systemprofile\AppData\Local\tauri and systemprofile\.cache to the
System32 originals. Verified afterwards on the runner: candle.exe
reports "WiX Toolset Compiler version 3.14.1.8722" and exits 0, and
makensis reports v3.11 and exits 0 — both from the same path that failed
before.

So both targets build again and the .msi asset comes back. Artifact
collection fails if either installer is missing rather than tolerating
an empty directory.

This is a host-side patch for a runner running as SYSTEM. A runner
running as a normal user has a LOCALAPPDATA outside System32 and needs
none of it.

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

.gitea/workflows/build-app.yml

@@ -454,23 +454,25 @@ jobs:
           TAURI_CONFIG: "{\"build\":{\"beforeBuildCommand\":\"\"}}"
         run: |
           set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%"
-          rem NSIS only: the MSI target needs WiX, whose candle.exe/light.exe are
+          rem Every Tauri bundler it downloads - candle.exe, light.exe and
-          rem 32-bit. On a runner running as SYSTEM, Tauri caches WiX under
+          rem makensis.exe - is 32-bit. A runner running as SYSTEM has
-          rem %LOCALAPPDATA% = C:\Windows\system32\config\systemprofile\..., and
+          rem %LOCALAPPDATA% under C:\Windows\system32\config\systemprofile, and
-          rem WOW64 redirection points 32-bit processes at SysWOW64, where that
+          rem WOW64 redirection sends 32-bit processes reading System32 to
-          rem directory does not exist - so candle cannot see its own folder and
+          rem SysWOW64, so they cannot see their own directory: candle exits
-          rem dies with 0x80131700. Tauri aborts the whole bundle when one target
+          rem 0x80131700 and makensis reports "Unable to start child process,
-          rem fails, so the MSI was also costing us the NSIS installer.
+          rem error 0x2".
           rem
-          rem NSIS is what the project ships for Windows upgrades anyway. To bring
+          rem The build VM carries junctions from the SysWOW64 view of
-          rem the MSI back, run the runner as a normal user (whose LOCALAPPDATA is
+          rem systemprofile\AppData\Local\tauri and systemprofile\.cache to the
-          rem outside System32) and restore --bundles msi,nsis.
+          rem System32 originals, which makes the redirected view resolve. A
-          cargo tauri build --bundles nsis
+          rem runner running as a normal user needs no such patch.
+          cargo tauri build --bundles msi,nsis
 
       - name: Collect artifacts
         run: |
           set "PATH=%USERPROFILE%\.cargo\bin;C:\Program Files\nodejs;%PATH%"
           mkdir artifacts
+          copy app\src-tauri\target\release\bundle\msi\*.msi artifacts\ || exit /b 1
           copy app\src-tauri\target\release\bundle\nsis\*.exe artifacts\ || exit /b 1
           dir artifacts\