[Desktop/Windows] VirtioFS Plan9 mount goes stale after VM idle, breaks workspace sessions

Environment

• Claude Desktop: v1.1.4328 (MSIX, Windows Store)
• OS: Windows 11 Enterprise 10.0.26200
• CPU: AMD Ryzen AI MAX+ PRO 395
• RAM: 96 GB

Bug 1: VirtioFS Plan9 mount goes stale after idle

After the workspace VM has been idle for ~30-50 minutes, new session spawns fail with:

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

The VM itself remains connected ([startVM] VM already connected), but the Plan9/VirtioFS filesystem sharing layer between the Windows host and the Linux guest has silently died. The 4 host directory mounts (.cowork, .claude, .skills, uploads) can no longer be established.

The error repeats on every retry until Claude Desktop is fully restarted.

Root Cause

The Hyper-V Plan9/VirtioFS connection degrades when the VM sits idle. The VM's RPC connection stays alive but the underlying filesystem sharing layer becomes stale — likely triggered by Windows power management (sleep/screen off) or VirtioFS daemon timeout.

Log Evidence

Session succeeds immediately after VM startup (07:34):

[Spawn:vm] id=c5f8d15e Spawn succeeded in 1190ms
[Process:c5f8d15e] Exited, code=0, signal=null, duration=12197ms, oom=false

~50 minutes of idle, then next session fails (08:25):

[Spawn:vm] id=a47d6627 Spawn failed: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Keepalive pings also fail during idle periods (observed on prior days):

[Keepalive] Ping failed: Keep-alive ping timed out

Bug 2: VM cannot restart after cowork-svc dies

When cowork-svc and vmwp are killed (or crash), Claude Desktop cannot restart the VM. The vmClient module loads and reports [startVM] VM already connected even though no VM process exists. The [VM:start] sequence is never triggered because it only fires when bundle files are missing.

Steps to reproduce

1. VM is running normally with bundle files present
2. cowork-svc.exe or vmwp.exe dies (crash, manual kill, or stale VirtioFS)
3. Restart Claude Desktop
4. vmClient loads, says "VM already connected" (stale state), never triggers [VM:start]
5. All spawn attempts fail with "VM service not running"

Workaround

Delete %APPDATA%\Claude\vm_bundles\claudevm.bundle to force a full re-download, which triggers the proper [VM:start] → [Bundle:status] rootfs.vhdx missing → download → startup path.

Expected Behavior

1. The VM should detect stale VirtioFS connections and automatically restart Plan9 shares or the VM itself.
2. When cowork-svc is not running, the vmClient should detect this and trigger [VM:start] regardless of whether the bundle files exist.