Don't fail VM enumeration on non-GUID compute system IDs

[oxc]

HcsEnumerateComputeSystems returns every compute system on the host, and not all of them use a GUID as their Id. Deserialising Id as a Uuid therefore makes one unrelated sibling abort the whole enumeration before the WSL entry is ever looked at:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidInput,
error: Error("UUID parsing failed: invalid length: expected one of [36, 32], found 18", line: 1, column: 186) }',
server\src\main.rs:96:18

On the affected machine hcsdiag list shows:

2A7D902F-C90B-4F92-87CB-EBB9F7D84E99
    VM,   Running, 2A7D902F-C90B-4F92-87CB-EBB9F7D84E99, WSL

cowork-vm-929216c6
    VM,   Running, D2B9750A-3588-5FF4-A2BC-7C0F86A95EB4, cowork-vm-929216c6

cowork-vm-929216c6 is the 18-character Id from the error. Since get_wsl_vmid_by_hcs only falls back to the registry on PermissionDenied, this is fatal rather than degraded.

This keeps Id as a String and parses it as a UUID only for the entry we actually want (Owner == "WSL"), and tolerates missing fields on the entries we don't care about.

Tested on the machine that hit the panic: wsldhost.exe now finds the correct VM ID and connects normally.

[Copilot]

Pull request overview

This PR hardens WSL VM discovery on Windows by preventing HcsEnumerateComputeSystems enumeration from failing when unrelated compute systems use non-GUID IDs.

Changes:

• Deserialize compute system Id as String (instead of Uuid) and only parse it for the Owner == "WSL" entry.
• Add #[serde(default)] to tolerate missing fields on non-WSL entries (e.g., owner, system_type, runtime_id, state).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[oxc]

Claude broke it, Claude fixed it 😂

AI Disclaimer: this PR was created by Claude Opus 5. The diagnosis is correct, and the fix works. Unfortunately, I cannot judge the added serde configs.

[oxc]

It might be worth considering moving to RuntimeId instead of Id. On my machine, this yields the same UUID, and always seems to be a UUID (also for the claude cowork container). I cannot tell whether this is guaranteed, though.

[nbdd0121]

RuntimeId is probably the corrrect ID to use, given that vsocks work only for running VMs anyway.