[FEATURE] Cowork VM uses fixed HCS identifier, preventing concurrent workspaces across multiple Claude Desktop instances

Summary

Cowork's workspace VM is created via the Host Compute Service (HCS) under a fixed identifier. When running two Claude Desktop instances on one Windows machine (separate data directories, e.g. for two accounts / swarm-style workflows), the second instance's workspace always fails to start while the first VM is running:

[VM:steps] create_vm_config started
[VM:start] VM boot failed: HCS operation failed: failed to create compute system:
HcsWaitForOperationResult failed with HRESULT 0x8037010f:
{"Error":-1070137073,"ErrorMessage":"A virtual machine or container with the specified identifier already exists."}
[VM:start] HCS error detected, available=true, missing=[], sentinel=HYPERVISOR_SERVICE_ERROR

The UI surfaces this as "Virtualization is not available — restart your computer," which is misleading: virtualization works, the first VM is running fine.

Steps to reproduce

Set up two Claude Desktop instances with redirected data dirs (e.g. C:\claude-instances\Account1, C:\claude-instances\Account2).
Start a Cowork workspace in instance A. VM boots normally.
Start a Cowork workspace in instance B → HYPERVISOR_SERVICE_ERROR (0x8037010f, identifier already exists).

Expected

Each instance can run its own workspace VM concurrently (unique HCS identifier per instance/bundle), or at minimum the error message should say another Cowork VM is already running instead of suggesting virtualization is broken.

Additional context from the same setup (related friction for multi-instance users)

CoworkVMService resolves bundle paths through MSIX LocalCache\Roaming virtualization, so bundles downloaded by apps with redirected data dirs are not found (failed to set VHDX path: VHDX file not found). Workaround requires moving bundles into ...\Packages\Claude_<id>\LocalCache\Roaming\<dir>\vm_bundles and junctioning the app-side path — note the service refuses to open its own path if it is a junction (is a symlink or junction, refusing to open), so the junction must be on the app side.
Service crashes on dirty shutdown (Event ID 7034, exit 1067) and each crash kills in-progress bundle downloads, which restart from zero — easily mistaken for a stalled/blocked download.

Environment

Windows 11 (AzureAD-joined), Claude Desktop 1.12603.1.0 (MSIX)
Bundle version 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
CoworkVMService: AUTO_START, LocalSystem, WIN32_PACKAGED_PROCESS