[BUG] Windows desktop app fails to launch after sleep/wake: "file in use by another program" (MSIX update blocked by lingering CoworkVMService)

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code

### What's Wrong?

**Description**

After the PC wakes from sleep, launching the Claude desktop app on Windows sometimes fails with a native error dialog:

> このファイルはほかのプログラムで使われています。(This file is being used by another program.)

reported from `C:\Program Files\WindowsApps\Claude_2.2553.1.0_x64__...`. The app cannot start at all. A full PC restart reliably fixes it until it recurs after a later sleep cycle.

**Root cause (from Windows Event Log investigation)**

The `Microsoft-Windows-AppXDeploymentServer/Operational` log shows a repeating pattern across several version bumps (1.52386.x → 2.110.x → 2.2553.x):

```
Warning (Id 658): {Claude_} is still running, marking package {Claude_} for deferred registration.
Error (Id 728, 0x80070015): Unable to notify pre-launch service for install/uninstall of app Claude_pzs8sxrjxfjjc!Claude / !SshProxy / !SshAskpass.
Error (Id 404/401/419, 0x80073D02): Deployment failed — the following app must be closed before it can be installed: Claude_.
```

In parallel, the `CoworkVMService` (binary: `...\app\resources\cowork-svc.exe`, the background service backing the Cowork/sandbox VM feature) repeatedly logs to the Application log:

```
Warning: Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.
Warning: Claude VM Service: failed to disarm SCM recovery actions for this stop; ... service may be auto-restarted during package servicing: open service: Access is denied.
```

with the service stopping/starting in a tight loop (observed multiple restarts within the same minute).

**Hypothesized mechanism**

1. The app auto-updates in the background. If the previous version's process or `CoworkVMService` is still holding file handles, MSIX registration of the new package is deferred instead of completing.
2. Windows attempts to finish this deferred package registration on resume from sleep.
3. If `CoworkVMService`/leftover processes still hold locks on package files at that moment, the resume-time registration attempt surfaces to the user as the native "file in use by another program" dialog, and the app fails to launch entirely.
4. A full reboot clears all handles, letting the deferred registration finish, which is why restarting "fixes" it until the next sleep/update cycle.

### What Should Happen?

The app should update cleanly without leaving the package in a "deferred registration" state, and/or `CoworkVMService` should release its file handles and shut down cleanly during package servicing so a sleep/wake cycle never surfaces a blocking "file in use" dialog on next launch.

### Error Messages/Logs

```
AppXDeploymentServer/Operational, Id 658:
{Claude_2.2553.0.0_x64__pzs8sxrjxfjjc} is still running, marking package {Claude_2.2553.1.0_x64__pzs8sxrjxfjjc} for deferred registration.

AppXDeploymentServer/Operational, Id 728:
Error 0x80070015: Unable to notify pre-launch service for install/uninstall of app Claude_pzs8sxrjxfjjc!SshProxy / !SshAskpass / !Claude.

AppXDeploymentServer/Operational, Id 404/401/419:
Error 0x80073D02: Cannot install because the following app must be closed: Claude_.

Application log, ProviderName=CoworkVMService:
"Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied."
"Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied."
```

### Steps to Reproduce

1. Use the Claude desktop app on Windows normally (with the Cowork/sandbox feature available, i.e. `CoworkVMService` present and set to Automatic startup).
2. Let the app sit while a background auto-update becomes available/pending.
3. Put the PC to sleep, then wake it.
4. Attempt to launch Claude from the Start menu / taskbar.

Result (intermittent, not every cycle): native dialog "このファイルはほかのプログラムで使われています。" (this file is being used by another program), and the app does not start.

**Workaround:** Restart the PC. This releases all handles and lets the deferred MSIX registration complete, after which the app launches normally again — until the next sleep + update cycle.

### Claude Model

Not applicable (fails before the app UI loads)

### Is this a regression?

Unknown — observed across multiple recent versions (1.52386.x through 2.2553.1.0), so likely a longstanding issue in the update/service lifecycle rather than a single-version regression.

### Last Working Version

N/A — recurs across versions

### Claude Code Version

2.2553.1.0 (Claude desktop app); bundled Claude Code CLI 2.1.275

### Platform

Windows

### Operating System

Windows 11 Pro (10.0.26200)

### Terminal/Shell

N/A (desktop app launch failure, occurs before any terminal/session starts)

### Additional Information

Diagnosed via PowerShell `Get-WinEvent` against the `Application` and `Microsoft-Windows-AppXDeploymentServer/Operational` logs. Happy to pull additional log excerpts (e.g. `C:\ProgramData\Claude\Logs\cowork-service.log`) if useful for reproduction.

Start by reproducing the sleep/wake update cycle and reviewing the AppXDeploymentServer/Operational and Application logs with PowerShell Get-WinEvent. Check C:\ProgramData\Claude\Logs\cowork-service.log alongside the CoworkVMService behavior; done means updates complete without deferred registration or file-lock errors and the app launches after wake.

Written by the indexing model from the issue text.