## What happened

Starting the Windows VM from the Omarchy menu (`Super` → type "windows" → **Windows**, which runs `uwsm app -- omarchy-windows-vm launch`) reliably fails with a critical notification **"Failed to start Windows VM"** whenever the VM container is already running. The container itself is healthy the whole time — the noVNC web console (`http://127.0.0.1:8006`) and a manual `xfreerdp3` connection both work fine during the "failure" — but `omarchy-windows-vm launch` exits before ever reaching the RDP step, so no RDP window opens.

## Root cause

`assert_mounts_safe()` in `omarchy-windows-vm` is called unconditionally at the top of `__priv_up_wait()`, even when the container is already `running`:

```sh
__priv_up_wait() {
  assert_mounts_safe || return 1
  local status
  status=$(docker inspect --format='{{.State.Status}}' "$CONTAINER" 2>/dev/null)
  if [[ $status != "running" ]]; then
    dc up -d || return 1
  fi
  ...
}
```

`assert_mounts_safe` requires the legacy/shared source directory (`~/Windows`, bind-mounted into the container as `/shared`) to be **exactly** mode `700`:

```sh
storage_mode=$(stat -Lc '%a' "/proc/.../fd/$storage_fd")
shared_mode=$(stat -Lc '%a' "/proc/.../fd/$shared_fd")
[[ $storage_mode != "700" ]] ...
[[ $shared_mode != "700" ]] ...   # fails here
```

While the `dockurr/windows` container is running, it manages `/shared` itself (Samba export for the guest) and continuously keeps the host-side directory's mode away from plain `700` (observed oscillating between `2700` and `2777`, i.e. with the setgid bit set, while the container is up). Running `chmod 700 ~/Windows` while the VM is active gets silently reverted within well under a second — it is not a one-off leftover state, it's actively re-asserted by the running container.

Net effect: **any `launch` call issued while the VM is already running will always fail this check**, even though nothing is actually wrong. Since `launch_windows()` treats `priv up_wait` failure as fatal (prints the error, fires the critical notification, and exits before the `xfreerdp3` block), the user gets a false "Failed to start Windows VM" notification and no RDP window, even on a perfectly healthy VM.

This also explains why a *first* launch (VM not yet running) generally succeeds: the directory is at rest at `700` before the container has had a chance to touch it.

## Steps to reproduce

1. `omarchy windows vm launch` (or via the menu) on a stopped VM — works, RDP window opens.
2. Close the RDP window *without* `--keep-alive` having stopped the VM, or start it with `-k`/`--keep-alive` and leave it running — or simply invoke `launch` a second time while the VM is still `running`.
3. Observe: `stat -c '%a' ~/Windows` reports something other than `700` (e.g. `2700`) while the container is up.
4. `omarchy windows vm launch` again (or click "Windows" in the menu again) → prints `❌ Failed to start Windows VM!`, fires a critical desktop notification, and exits — despite `omarchy windows vm status` showing `RUNNING` and the web console / RDP both being reachable.

## Expected behavior

Launching against an already-`running` VM should not fail (and should not require `~/Windows` to be exactly `700`) — it should skip straight to connecting with `xfreerdp3`, the same way it skips `dc up -d` when `status == running`. At minimum, `assert_mounts_safe` should only be enforced on the actual bring-up path (`dc up -d`), not when just reconnecting to an already-running container.

## System details

- Omarchy version: 4.0.0.r2186.gee8ebf6-1
- Kernel: 7.2.6-arch2-1
- CPU: AMD Ryzen 7 PRO 250 w/ Radeon 780M Graphics
- GPU: AMD HawkPoint1 (integrated, Radeon 780M)
- Docker: 29.8.1
- FreeRDP: 3.32.1
- Filesystem: Btrfs (`/home` subvolume)