fix(self-update): minimal asInvoker manifest — stop uffs-update.exe SxS crash (os error 14001)

crates/uffs-update/app.manifest

@@ -3,39 +3,31 @@
   SPDX-FileCopyrightText: 2025-2026 SKY, LLC.
   SPDX-License-Identifier: MPL-2.0
 
-  uffs-update application manifest.
+  uffs-update application manifest — deliberately MINIMAL.
 
-  CRITICAL: the `asInvoker` requestedExecutionLevel below is what stops
-  Windows' "Installer Detection" heuristic from force-elevating this binary.
-  That heuristic auto-flags executables whose NAME contains update/setup/
-  install/patch as installers needing UAC — so `uffs-update.exe` would
-  otherwise fail to launch from the non-elevated `uffs.exe` with
-  ERROR_ELEVATION_REQUIRED (os error 740), breaking every `uffs --update`
-  operation. The self-update helper only rewrites files in the user's own
-  install dir; it never needs Administrator.
+  CRITICAL: the `asInvoker` requestedExecutionLevel below is the *one* thing
+  this manifest exists to declare. It stops Windows' "Installer Detection"
+  heuristic from force-elevating this binary purely because its NAME contains
+  "update" — without it, `uffs.exe` (non-elevated) cannot spawn
+  `uffs-update.exe`; it fails with ERROR_ELEVATION_REQUIRED (os error 740),
+  breaking every `uffs --update` operation. The self-update helper only
+  rewrites files in the user's own install dir; it never needs Administrator.
+
+  WHY MINIMAL — nothing but `trustInfo`: an earlier, richer version of this
+  manifest (with `<assemblyIdentity>`, a `<compatibility>` supportedOS block,
+  and `<windowsSettings>`) made the cross-compiled `uffs-update.exe` fail to
+  start at all with ERROR_SXS_CANT_GEN_ACTCTX (os error 14001, "side-by-side
+  configuration is incorrect"). `<assemblyIdentity>` in an application manifest
+  makes the loader attempt a side-by-side assembly resolution that can fail;
+  this helper is a plain console binary that needs none of those settings. Keep
+  this file to `trustInfo`-only so there is zero SxS activation-context surface.
 -->
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
-  <assemblyIdentity type="win32" name="UFFS.Update" version="0.0.0.0"/>
-
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
     <security>
       <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
       </requestedPrivileges>
     </security>
   </trustInfo>
-
-  <application xmlns="urn:schemas-microsoft-com:asm.v3">
-    <windowsSettings>
-      <!-- Long-path support for deep install/staging paths (> 260 chars). -->
-      <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
-    </windowsSettings>
-  </application>
-
-  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
-    <application>
-      <!-- Windows 10 / 11 (shared supportedOS GUID per MS docs). -->
-      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
-    </application>
-  </compatibility>
 </assembly>

crates/uffs-update/build.rs

@@ -18,6 +18,10 @@
 //! (os error 740) — breaking every `uffs --update` operation on Windows. The
 //! helper only rewrites files in the user's install dir; it never needs admin.
 //!
+//! The manifest is intentionally minimal (`trustInfo`-only): a richer earlier
+//! version tripped `ERROR_SXS_CANT_GEN_ACTCTX` (os error 14001) so the binary
+//! would not start at all. See `app.manifest` for the full rationale.
+//!
 //! Inert on non-Windows / non-MSVC targets (the helper ships windows-msvc).
 
 fn main() {