CoworkVMService fails to configure SCM recovery actions — "Access is denied" on every start

**Environment**
- Claude Desktop (Windows, MSIX package `Claude_1.46388.4.0_x64__pzs8sxrjxfjjc`)
- Windows 10 IoT Enterprise LTSC 2021 (10.0.19044)

**Description**

The `CoworkVMService` Windows service (`cowork-svc.exe`, DisplayName "Claude") logs the following warnings in the Application event log on every service start/stop:

```
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.
```

**Root cause (from inspecting the service ACL via `sc sdshow CoworkVMService`)**

```
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...)
```

- `Authenticated Users` (AU) are granted query/status/start/stop/pause rights but **not `SERVICE_CHANGE_CONFIG` (DC)**.
- Only the service's own per-service SID (`NT SERVICE\CoworkVMService`) has full rights including `DC`/`WD`/`WO`.

When the service tries to call `ChangeServiceConfig2` (to set `SERVICE_CONFIG_FAILURE_ACTIONS`) on itself at runtime, it appears to do so without holding a handle opened with `SERVICE_CHANGE_CONFIG` rights under the current token, resulting in `Access is denied`.

**Impact**

Low severity — `ERROR_CONTROL` is set to `IGNORE`, so this doesn't block startup. The only real consequence: if `CoworkVMService` crashes, it will not auto-restart until the machine is rebooted (per the log message itself).

**Suggested fix**

Either:
1. Grant `SERVICE_CHANGE_CONFIG` to the appropriate principal in the service's installed ACL (via the MSIX service manifest), or
2. Have the service open its own SCM handle using its per-service SID/token (which already has full rights) rather than the caller's default token, or
3. Skip/soft-fail this configuration step without logging it as a recurring warning if it's expected to fail in this deployment mode.

**Reproduction**

Happens on every Claude Desktop start on this machine — visible in Event Viewer → Windows Logs → Application, source `CoworkVMService`, occurring alongside `Claude VM Service starting.` entries.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by locating the CoworkVMService/cowork-svc.exe service setup and any MSIX service manifest or startup code that calls ChangeServiceConfig2 for SERVICE_CONFIG_FAILURE_ACTIONS. Reproduce on Windows by starting Claude Desktop and checking Event Viewer > Windows Logs > Application for the listed CoworkVMService warnings. Done means the recurring Access is denied warnings no longer appear, or are intentionally soft-failed, and recovery-action handling is correct for this deployment mode.

Written by the indexing model from the issue text.