Windows (MSIX): after auto-update relaunch, Claude cannot start (0x80070020) - old app container stays mounted with no process holding it

## Summary

On Windows 11, after the desktop app's in-app auto-update quits and relaunches itself ("stealth update"), the new version sometimes cannot start at all. Every launch fails with Windows error **0x80070020** ("The process cannot access the file because it is being used by another process") before any app code runs, so `main.log` shows nothing. *Settings > Apps > Claude > Repair* does not help (tried 5x). The old version's Desktop AppX container is still mounted, and on the second machine we confirmed that **no user-mode process holds any handle into it** — so the leftover reference is on the Windows side, and only signing out of Windows (or rebooting) clears it.

Seen on two different PCs, two different updates:

- PC 1: 2026-09-11, update 1.52386.0 -> 1.52386.3. Unusable until a reboot on 2026-09-13.
- PC 2: 2026-09-17, version 2.2553.0.0 (stale container from the previous version's relaunch). Fixed by sign-out/in.

## Environment

- Claude desktop, Microsoft Store / MSIX build (`Claude_pzs8sxrjxfjjc`), versions above
- Windows 11 Home 10.0.26200 (PC 1); Windows 11 (PC 2)
- Claude Code (Code tab) sessions were open in the app at the time of the update on PC 1

## What the logs show (PC 1, 2026-09-11 14:36)

`main.log`:

```
14:36:57 [stealth-update] Triggering stealth update after idle timeout
14:36:57 [CCD] Killing 1 PTY process tree(s) on quit
14:36:57 beforeQuitForUpdate handler fired, going down for update
14:36:57 Windows session ending (close-app) - quitting the app
(no "Starting app" line until after the reboot on 09-13 06:37)
```

Event log *Microsoft-Windows-AppModel-Runtime/Admin*, same second:

```
14:36:58 217 Destroyed Desktop AppX container {3EC63A37-...} for package Claude_1.52386.0.0_...
14:36:58 215 0x80070020: Cannot create the Desktop AppX container for package Claude_1.52386.3.0_... because an error was encountered converting the job.
14:37:01 208 0x80070020: Cannot create the process for package Claude_1.52386.3.0_... because an error was encountered while configuring runtime. [LaunchProcess]
```

The old version had two containers (3EC63A34 and 3EC63A37, created 2026-09-10 16:26 by the previous update's relaunch). The update destroyed only 3EC63A37; **3EC63A34 survived until the user signed out on 2026-09-13 06:29:17**, and every launch attempt and every Repair in between produced the same 215/208 pair. Repair recycled the CoworkVMService container fine each time; the app container never came back.

## What the diagnostics show (PC 2, 2026-09-17, run elevated)

```
Installed package: Claude_2.2553.0.0_x64__pzs8sxrjxfjjc
No Claude processes are running. (tasklist /apps + Win32_Process, elevated)
User.dat : LOCKED
UserClasses.dat : LOCKED (...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium)
hivelist: \REGISTRY\WC\Silof39f9b06-e6a6-59fc-488a-0eb0e534d01cuser_sid = ...\Helium\User.dat
hivelist: \REGISTRY\WC\Silof39f9b06-e6a6-59fc-488a-0eb0e534d01cuser_classes = ...\Helium\UserClasses.dat
handle -a f39f9b06-e6a6-59fc-488a-0eb0e534d01c -> No matching handles found.
```

and on each launch:

```
215 0x80070020: Cannot create the Desktop AppX container for package Claude_2.2553.0.0_... because an error was encountered converting the job.
208 0x80070020: Cannot create the process for package Claude_2.2553.0.0_... because an error was encountered while configuring runtime. [LaunchProcess]
```

So the silo that holds the per-user package hive is still mounted, no Claude process exists, and no process at all has a handle into the silo. Stopping/restarting CoworkVMService does not release it.

## Workarounds found

- Sign out of Windows and back in (reliable, no full reboot needed).
- If an old-version process *is* still alive (compare `tasklist /apps` against `Get-AppxPackage Claude`), killing it works.

## Expected

Either the update relaunch waits for / tears down the old container before starting the new version, or the launcher detects this state and tells the user to sign out instead of failing silently (the user only sees a generic "file in use" dialog and Repair does nothing).

## Suspicion

The relaunch after `beforeQuitForUpdate` starts the new version while the previous container is still being torn down (the second container of the old version was created by the *previous* update's relaunch and is destroyed only at sign-out). Something in that sequence leaks a reference to the old app container/silo.

Start with the stealth-update and beforeQuitForUpdate sequence described in the issue, then reproduce the MSIX relaunch while checking AppModel-Runtime/Admin events and the package-container state. Done means the updated app launches without a stale container, or the launcher gives a clear sign-out instruction when Windows has not released the old container.

Written by the indexing model from the issue text.