## What happened

After using the Windows VM's shared folder (`~/Windows` on the host, mounted into the guest as the "Shared" folder), `omarchy-windows-vm launch` starts failing with a bare, unhelpful error and no indication of the cause:

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

This recurs on essentially every launch after the shared folder has been used — not a one-off. It reappeared repeatedly across separate sessions on this machine, and was even observed reappearing after only ~1 minute of VM uptime with no unusual guest-side activity beyond having the folder present on the desktop.

## Why (root cause)

The Windows VM's own file-sharing service (this image shares `/shared` with the guest, presumably via Samba) sets the setgid bit on the shared folder while the VM is running. Because `/shared` inside the container is a bind mount of a root-owned anchor (`/var/lib/omarchy/windows/mounts/users/<uid>/shared`), which is itself bind-mounted from `~/Windows` on the host, this permission change propagates straight back to the host source directory — `~/Windows` ends up as `2700`/`drwx--S---` instead of `700`.

`omarchy-windows-vm`'s own mount-safety check, `mounted_leaf_matches()`, requires the mode to be *exactly* `700`:

```bash
mounted_leaf_matches() {
  ...
  [[ $actual == "$identity" && $owner == "$CALLER_UID" && $mode == 700 ]]
}
```

So the very next `launch` after any session that touched the shared folder fails this check — and fails **silently**: none of `assert_boundary_dir`, `with_vm_lock`, or the `mounted_leaf_matches` call path inside `bind_mount_leaf`'s "already correct" branch echo anything in this particular failure shape, so the user just sees the generic top-level "❌ Failed to start Windows VM!" with zero indication of what actually went wrong or where. Diagnosing this required manually tracing the elevated call with `pkexec bash -x /usr/bin/omarchy-windows-vm __priv up_wait 2>&1`.

### Compounding issue: `chmod` can't reliably fix it either

The obvious manual fix, `chmod 700 ~/Windows` (or the same on the mount anchor), is unreliable on this system: GNU coreutils `chmod` (9.11-2) reports success but silently **does not clear the setgid bit** — printed as `mode of '...' retained as 2700 (rwx--S---)` — even when run as root, while other bits changed in the same call (e.g. `2755` → `2700`, where `755`→`700` applied but the setgid bit did not clear) do get applied correctly. Only a raw `chmod(2)`/`fchmodat(2)` syscall via Python's `os.chmod()` reliably clears it:

```python
python3 -c "import os; os.chmod('/var/lib/omarchy/windows/mounts/users/1000/shared', 0o700)"
```

This may be a separate coreutils/kernel/btrfs interaction bug rather than an Omarchy bug per se, but it's what turns this from "annoying" into "very hard to self-diagnose and fix" for anyone hitting it without noticing the discrepancy between `chmod`'s reported success and its actual effect. Filesystem: btrfs (`/@home` subvolume).

## Expected

Either:
- `omarchy-windows-vm` should defensively normalize the shared-folder anchor's permissions itself before checking (it already knows the expected mode), rather than hard-failing on a state its own container caused, or
- at minimum, the failure paths in `assert_boundary_dir` / `with_vm_lock` / `mounted_leaf_matches` should echo *why* they refused, so users aren't left with only the generic top-level message.

## Steps to reproduce

1. Set up the Windows VM with default settings on a btrfs home.
2. `omarchy-windows-vm launch`, let Windows boot, and let the shared folder be visible/used in the guest (no unusual action needed).
3. Stop the VM (`omarchy-windows-vm stop`, or close RDP without `-k`).
4. `stat -c '%a' ~/Windows` → shows `2700` instead of `700`.
5. `omarchy-windows-vm launch` again → fails with the generic error.

## Workaround

```bash
python3 -c "import os; os.chmod('/var/lib/omarchy/windows/mounts/users/1000/shared', 0o700)"
omarchy-windows-vm launch
```
(Using plain `chmod` here often does not work — see above.)

## System details

- Omarchy version: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- coreutils: 9.11-2
- Filesystem: btrfs (`/@home` subvolume)
- Docker: 29.7.2, Docker Compose 5.5.0
- dockurr/windows image, Windows 11 guest