CoworkVMService fails to configure its own crash-recovery action (Access is denied), so the desktop app doesn't self-heal after a crash

## CoworkVMService fails to configure its own crash-recovery action ("Access is denied"), so the desktop app doesn't self-heal after a crash

**Environment**
- Windows 11 Home, build 26200.9445
- Claude desktop app version 1.52386.6.0 (MSIX package `Claude_1.52386.6.0_x64__pzs8sxrjxfjjc`)
- Service: `CoworkVMService` ("Claude" VM Service), binary `cowork-svc.exe`, runs as `LocalSystem`

**What happened**

The desktop app became unresponsive/closed and would not reopen. Restarting the machine fixed it.

Checking the Application event log around the time of the incident shows `CoworkVMService`
repeatedly failing to configure its own SCM recovery actions on every start/stop cycle:

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

This happened 3 times in ~5 minutes (09:32:31, 09:34:06, 09:36:57) before a full reboot resolved
it, suggesting the service (or the app trying to relaunch it) was stuck retrying without success.

**Root cause (confirmed via `sc.exe sdshow CoworkVMService`)**

The service's own security descriptor does not grant it `SERVICE_CHANGE_CONFIG` (`DC`) against
itself for the security principal its `LocalSystem`-run process actually gets evaluated under:

```
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
```

- The first ACE (Authenticated Users) grants `CC,LC,SW,RP,WP,DT,LO,CR,RC` — no `DC`.
- The second ACE is scoped to what looks like the service's own per-service SID
(`S-1-5-80-...`), which *does* include `DC`/`WD`/`WO` — but that SID is only present in a
process token when the service's `SidType` is configured to include it (`sc.exe qsidtype`).
Since the service runs as plain `LocalSystem` without that SID active in its token, it only
gets evaluated against the first ACE (via Authenticated Users membership) — which lacks the
config-change right it's trying to exercise on itself at startup.

So on every start, `cowork-svc.exe` calls what's presumably `ChangeServiceConfig2` (to set
`SERVICE_CONFIG_FAILURE_ACTIONS_FLAG` / restart-on-crash) against its own service handle, and
that call is denied by the DACL the installer shipped. `ERROR_CONTROL` on the service is `IGNORE`
already, so there's no OS-level safety net either — if the process ever actually crashes, nothing
restarts it until a full reboot, which matches the reported symptom exactly.

**Suggested fix**

Either:
1. Ship the MSIX installer with a DACL that grants `LocalSystem` (`SY`) explicit
`SERVICE_CHANGE_CONFIG` on `CoworkVMService`, e.g. add `(A;;CCDCLCSWRPWPDTLOCRRC;;;SY)`, or
2. Set the service's `SidType` to `unrestricted` so its own per-service SID (already granted the
right rights in the shipped DACL) is actually present in its token at runtime, or
3. Have `cowork-svc.exe` open its own service handle with the access it actually has, and skip
trying to configure recovery actions on itself if `SERVICE_CHANGE_CONFIG` isn't available,
rather than logging a warning and leaving that safety net silently unconfigured every time.

Happy to provide the full event log export if useful.