## What happened

`omarchy windows vm launch` (and the app-menu launcher) fails with:

```
Starting Windows VM (this may prompt for authorization)...
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```

...even though the VM is actually already running and fully healthy (`omarchy windows vm status` reports RUNNING, RDP on 3389 connects fine, `docker inspect` shows the container `running`).

## Root cause

In `/usr/bin/omarchy-windows-vm`:

- `launch_windows()` calls `priv up_wait` → `__priv_up_wait()` (around line 902), which calls `assert_mounts_safe()` (line 839) before ever checking whether the VM already reports ready.
- `assert_mounts_safe()` calls `mounts_ready()` (line 618), which calls `open_mount_source()` (line 313) against `$LEGACY_STORAGE` (`$HOME/.windows`) to verify the bind-mount anchor's pinned identity.
- `open_mount_source()` scans that directory with a hard-coded timeout (lines 35-36, used at lines 390-391):

  ```bash
  TREE_SCAN_TIMEOUT_SECONDS=5
  TREE_SCAN_KILL_AFTER_SECONDS=1
  ...
  found=$("$TREE_SCAN_TIMEOUT" --signal=TERM --kill-after="${TREE_SCAN_KILL_AFTER_SECONDS}s" \
    "${TREE_SCAN_TIMEOUT_SECONDS}s" "$TREE_SCAN_FIND" -P "/proc/$BASHPID/fd/$root_fd/." ...)
  ```

- `$HOME/.windows` contains the VM's real disk images (in my case a 64 GB `data.img`, an 8.4 GB `win11x64.iso`, plus the UEFI vars/rom files). The 5-second `timeout` on the `find` tree-scan does not reliably complete against a directory holding multi-GB sparse disk images, especially while the VM is actively writing to `data.img`.
- When the scan times out, `open_mount_source` / `mounts_ready` return non-zero **with no error message on this specific path** (the caller in `assert_mounts_safe` does print `"omarchy-windows-vm: refusing an unsafe VM mount anchor"` on a `mounts_ready` failure, but in my testing via `pkexec` that stderr did not surface back to the invoking terminal either — the user just sees the generic "❌ Failed to start Windows VM!" from `launch_windows()` with no indication of *why*).
- Net effect: a perfectly healthy, already-running VM gets reported as failed to start, purely because of an unrelated security tree-scan that can't finish in 5s against realistic disk sizes.

## Expected

`omarchy windows vm launch` should succeed (or at least clearly report the real reason) when the VM is already running and reachable, regardless of how large the on-disk VM image files are.

## Steps to reproduce

1. `omarchy windows vm install` and let Windows finish installing (real installs end up with a many-GB `data.img` under `~/.windows`).
2. With the VM already running (`omarchy windows vm status` → RUNNING), run `omarchy windows vm launch` (or launch "Windows" from the app menu).
3. Observe the spurious `❌ Failed to start Windows VM!` even though the VM is healthy and connectable via RDP on 127.0.0.1:3389.

## Workaround

Connect directly, bypassing the wrapper's readiness check:

```bash
xfreerdp3 /u:<user> /p:'<pass>' /v:127.0.0.1:3389 -grab-keyboard /sound /microphone /clipboard /cert:ignore /dynamic-resolution /gfx:AVC444 /f
```

## System details

- `omarchy version`: 4.0.2-1
- `uname -a`: Linux omarchy 7.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 21 Aug 2026 22:18:59 +0000 x86_64 GNU/Linux
- CPU: AMD Ryzen AI 7 450 w/ Radeon 860M
- GPU: NVIDIA GeForce RTX 5060 Max-Q / Mobile
- `~/.windows` contents at time of failure: `data.img` (64 GB, sparse, actively written by the running VM), `win11x64.iso` (8.4 GB), plus `windows.rom`/`windows.vars`/`setup.img` and small metadata files.

## Suggested fix direction

- Raise `TREE_SCAN_TIMEOUT_SECONDS` (or make it configurable / scale with directory size), and/or
- Skip the mount-safety re-verification in `up_wait` when the container already reports `running` and the guest already reports ready (i.e. check "is it already up" before paying the tree-scan cost), and/or
- Have `launch_windows()` surface the real stderr from the elevated `assert_mounts_safe`/`mounts_ready` failure instead of the generic "❌ Failed to start Windows VM!" message, so this class of failure is at least diagnosable without reading the script source.