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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.