Harden Windows desktop packaging build object identity after functional release

[integry]

Objective

Close post-MVP Windows build-time object-identity races after #1972 delivers functionally green six-platform packages. This issue is deliberately not a release blocker for the first desktop epic unless a runtime/package trust boundary depends on the affected build-only path.

Scope

• Bind canonical takeown/icacls OS-tool validation to execution without a pathname ABA gap, or prove the protected System32 directory and file ACL/signer guarantees make replacement impossible for the supported attacker model.
• Validate owner, effective DACL, reparse tag, volume/file identity, signer and final executed image for the fixed OS tools without PATH or environment lookup.
• Hold or revalidate the exact staging root identity through the multi-tool DACL transition; reject swap/delete/rename and attacker-planted explicit/inherited ACEs.
• Preserve strict runtime packaged-authority ownership; this is build-only hardening.
• Add deterministic hostile barrier tests on native x64 and ARM64 runners.

Dependency and integration

Start only after #1972 is integrated into the Electron runtime epic so this work targets the reviewed packaging implementation. Add the AI label and the correct descendant base label at that point. Require exact-head Ultrafix and native Windows CI. Do not target or merge directly to main.

Part of #1950, #1952, and #1957.

[integry]

Additional deferred build-only scope from packaging PR #1972 at 44561fae8c5682b7d108a408fcb53fd6e6ca1cf9: maintain or automate the static Windows servicing catalog allowlist/pin policy without monthly hosted-image churn. The functional release will retain fixed canonical System32/.NET roots, held non-reparse files, trusted owner/DACL, real CryptCATAdmin SHA-256 catalog membership, offline WinVerifyTrust/Microsoft system-component publisher policy, and exact catalog/input hashes plus file identities in build evidence, but will not hard-code catalog basename/hash/cert/SPKI tuples for unsigned build mode. #1998 should restore a managed deterministic servicing policy if it can remain compatible with supported x64/ARM64 hosted images, with hostile wrong-member/wrong-chain tests. Current observed legitimate rotations: x64 ServerCore 10.0.26100.33296.cat hash f93ebbd0…; ARM64 Client Features 10.0.26100.9168.cat hash 59e02d4b….

[integry]

Further deferred scope from #1972 after exact 5cd8eb9564b5deda034b7acd3fefda8edb150241: the custom held compiler/reference/catalog image proof, suspended compiler process/job assignment, and retained object identity through compiler exit. The functional release branch will use the canonical fixed GetSystemWindowsDirectory/.NET Framework csc.exe and fixed references with argv/no shell, bounded environment/time/output, private source/output, and post-build PE/hash/manifest/package checks. #1998 should restore the stronger held compiler execution/catalog/job/object proof with actionable fixed diagnostics and hostile replacement tests once it can run reliably across x64/ARM64 hosted Windows. Runtime helper/launcher authentication, packaged hashes, SYSTEM/protected DACL, Authenticode/update pins, MSI validation, and runtime mode prohibition remain release requirements and are not deferred.