CoworkVMService file lock persists after suspend/resume on Modern Standby (S0) systems; neither Power-Troubleshooter Event ID 1 nor SystemEvents.PowerModeChanged fire on resume

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

After the PC suspends and resumes, relaunching Claude Desktop fails with "Another program is currently using this file," referencing a file under the MSIX package path. Root cause traced to cowork-svc.exe (CoworkVMService) holding a lock that a plain taskkill/process-kill does not release — consistent with the file-lock behavior reported in #48787, #49655, and #46179, but triggered by suspend/resume rather than an app update.

Additional finding (may be useful beyond this specific bug): Attempted to build a workaround that auto-restarts the service on resume. Two standard Windows resume-detection mechanisms were tested and neither fired on this Modern Standby system:

Windows Event Log, System channel, source Microsoft-Windows-Power-Troubleshooter, Event ID 1 — task never triggered across multiple confirmed suspend/resume cycles.
.NET SystemEvents.PowerModeChanged (the WM_POWERBROADCAST-based resume notification) — confirmed listener was running before resume; no event fired after resume.

This suggests any internal Anthropic logic for detecting resume-from-sleep (if used to restart CoworkVMService, refresh VM state, etc.) may also be unreliable on Modern Standby hardware, since these are the standard OS-level signals apps use for that purpose.

### What Should Happen?

File lock should be released for cleanly closing the Claude's VM

### Error Messages/Logs

```shell

```

### Steps to Reproduce

Steps to Reproduce:

Install Claude Desktop on Windows via the Microsoft Store/MSIX installer (not the legacy Electron installer).
Ensure Cowork is enabled and has been used at least once, so CoworkVMService is registered and running (cowork-svc.exe).
Confirm the system uses Modern Standby: run powercfg /a in an elevated Command Prompt — it should list Standby (S0 Low Power Idle) as supported and Standby (S3) as not supported.
With Claude Desktop closed (or open), suspend the PC (Start → Power → Sleep, or close the lid if a laptop).
Resume the PC.
Attempt to open Claude Desktop.

Expected result: App opens normally.

Actual result: Error dialog: "Another program is currently using this file", referencing a path under C:\Program Files\WindowsApps\Claude__....

To confirm the root cause is CoworkVMService:
7. Open Task Manager / PowerShell, and note that cowork-svc.exe is still running after the error appears.
8. Force-killing just claude.exe does not resolve the error; the file lock persists until CoworkVMService itself is stopped (net stop CoworkVMService) and restarted.

### Claude Model

Other

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

1.46388.3.0

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

_No response_

Start by reproducing the suspend/resume sequence on a Windows Modern Standby system, confirming S0 support with `powercfg /a` and checking whether cowork-svc.exe still holds the MSIX file lock. Investigate the CoworkVMService resume and shutdown lifecycle; done means Claude Desktop relaunches successfully after resume without requiring the service to be manually stopped and restarted.

Written by the indexing model from the issue text.