Windows: ship an MSIX package alongside the portable exe

Roadmap item, accepted 2026-06-11. MSIX joins the Windows artifact set as an **additional** package — the portable exe stays (installer-less users are a real audience, and the exe is the MSIX's content anyway).

## Why

- **Identity-bound packaging**: MSIX upgrade identity = `Name` + `Publisher`. Artifact Signing rotates certificates daily but keeps the subject DN stable, so package identity stays stable across releases — the two pair well.
- Clean install/uninstall (WindowsApps container), App Installer UX, and a future winget entry can point at it.
- Artifact Signing signs MSIX natively with the same signtool/dlib flow we already run; `makeappx` ships in the Windows SDK on the runners. No Advanced Installer needed for a one-exe package.

## Prerequisites (ordered)

1. #208 merged, dry-run green on both arches, and the **portable exe runtime-verified** on real Windows (x64 + arm64) — the bare-exe channel only first worked in v0.6.6 and immediately hit the VCRUNTIME140 issue #208 fixes.
2. **Agent runtime-tested** (#167 follow-up). An MSIX of the agent-less GUI is an empty shell; the package only earns its keep once it carries GUI + agent + autostart.

## Work items

- **AppxManifest**: package identity with `Publisher` **byte-matching the Artifact Signing certificate subject DN** (all RDN fields, same order — `SignerSign()` fails otherwise; store the DN in the Azure 1Password item next to the other signing config); `runFullTrust`; a `StartupTask` extension for the agent.
- **Autostart**: under MSIX, HKCU writes are copy-on-write virtualized into a per-package hive, so the #167 `winreg` `HKCU\...\Run` entry would never fire at login. `StartupTask` is the sanctioned replacement; keep the winreg path for the portable exe.
- **CI** (release.yml windows job): sign the exe(s) → `makeappx pack` → sign the `.msix` with the same artifact-signing-action invocation. Dry-run workflow tracks it per its sync contract.
- **gpui-updater**: detect an MSIX install (read-only WindowsApps root) and no-op the self-replace path — it cannot work there. MSIX updates flow via a published `.appinstaller` file instead (or defer MSIX auto-update initially and let users update via the release page/winget).
- **winget**: a manifest pointing at the signed portable exe can land before any of this and already gives the "proper install" UX; switch it to the MSIX once that ships.

## Constraints to keep in mind (verified)

- `ms-appinstaller://` has been **disabled by default since Dec 2023** ([MSRC, CVE-2021-43890 update](https://msrc.microsoft.com/blog/2023/12/microsoft-addresses-app-installer-abuse/)) — there is no browser one-click install; users download the `.msix` and SmartScreen reputation applies to that download exactly as it does to the exe. MSIX improves the post-download install/upgrade/uninstall experience, not download trust.
- [MSIX container semantics](https://learn.microsoft.com/en-us/windows/msix/msix-container) / [flexible virtualization](https://learn.microsoft.com/en-us/windows/msix/desktop/flexible-virtualization): registry/AppData virtualization is opt-out-able via `unvirtualizedResources`, but prefer the sanctioned `StartupTask` over fighting the container.
- [Signing guide](https://learn.microsoft.com/en-us/windows/msix/package/sign-msix-package-guide) / [troubleshooting](https://learn.microsoft.com/en-us/windows/msix/msix-troubleshooting-guide) for the Publisher/subject matching rule.

Start with the ordered #208 and #167 prerequisites, then read the Windows job in release.yml, the AppxManifest requirements, and the gpui-updater entry point. Done means the signed MSIX ships alongside the portable exe, uses a StartupTask for the agent, and avoids self-replacement for MSIX installs.

Written by the indexing model from the issue text.