## Summary

`omarchy windows vm launch` (and the "Windows" desktop launcher) fails with
**"❌ Failed to start Windows VM!"** even when the Windows container is running
and healthy. The failure is actually in the mount-safety check, not in starting
the VM, so the message is misleading.

**Root cause:** in `bin/omarchy-windows-vm`, `prepare_caller_mounts()`
normalizes the bind-mount source directories with a **numeric** `chmod 0700`,
then asserts each is exactly mode `700`. GNU `chmod` with a *numeric* mode does
**not** clear the **setgid** bit on a *directory* (only a symbolic `g-s` does).
After a VM session the shared folder `~/Windows` carries the setgid bit
(mode `2700`), so `stat -c %a` returns `2700`, the `[[ $shared_mode != 700 ]]`
guard trips, `prepare_caller_mounts` returns 1, `assert_mounts_safe` fails, and
`__priv_up_wait` returns 1 — surfaced by `launch_windows` as
"Failed to start Windows VM!".

## Steps to reproduce

1. `omarchy windows vm install`, complete the Windows install, log in, use the
   VM, then shut Windows down.
2. Run `omarchy windows vm launch` (or click the "Windows" app) again.
3. → **"❌ Failed to start Windows VM!"**, even though the container starts fine
   and RDP is reachable.

After a session, `~/Windows` is mode `2700` (setgid). The bit is applied during
the VM run — the dockur/windows container provisioning the `/shared` Samba
share, which is bind-mounted from `~/Windows`.

## Root-cause detail

`prepare_caller_mounts()` in `bin/omarchy-windows-vm`:

```bash
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
  exec {storage_fd}<&-
  exec {shared_fd}<&-
  return 1
}
storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd" 2>/dev/null) || storage_mode=""
shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd" 2>/dev/null) || shared_mode=""
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  exec {storage_fd}<&-
  exec {shared_fd}<&-
  return 1
fi
```

The `chmod 0700` is meant to normalize the mode, but on a **directory** GNU
coreutils preserves the setuid/setgid bits for numeric modes, so a `2700`
source stays `2700` and the equality check fails.

Minimal, self-contained repro (GNU coreutils 9.11):

```console
$ d=$(mktemp -d); chmod 2700 "$d"; stat -c %a "$d"   # 2700
$ chmod 0700 "$d"; stat -c %a "$d"                    # 2700   <-- setgid NOT cleared
$ chmod g-s "$d"; stat -c %a "$d"                     # 700    <-- symbolic clears it
```

Trace of the failing privileged action (`__priv up_wait`, run under `bash -x`):

```
+ chmod 0700 -- /proc/.../fd/11 /proc/.../fd/12
+ storage_mode=700
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ return 1
```

## Suggested fix

Explicitly clear the special bits with a symbolic mode alongside the numeric
chmod, e.g.:

```bash
chmod 0700 -- "$a" "$b" && chmod ug-s -- "$a" "$b" || { …; return 1; }
```

Actually clearing the bit is preferable to loosening the check, so the bind
source is genuinely `700`. The same "numeric `chmod` then compare `== 700`"
pattern appears in the other anchor/source validation paths too, so it is worth
auditing all of them (`mounted_leaf_matches`, `prepare_boundary_component`,
etc.).

Separately: consider making the user-facing message distinguish a mount-safety
rejection from a genuine start failure — "Failed to start Windows VM!" is
confusing when the VM is actually running.

## Workaround

```bash
chmod g-s ~/Windows   # before launching
```

## System

- Omarchy: **4.0.2-1**
- Kernel: 7.1.9-arch1-2 (Arch Linux)
- CPU: Intel Core i7-11850H
- GPU: Intel UHD Graphics (TigerLake-H) + NVIDIA RTX A2000 Mobile
- RAM: 62 GB
- Docker: 29.7.2 · Compose: 5.5.0
- coreutils: 9.11
- Image: `dockurr/windows@sha256:0cff9eb0e7aee9953e55bc682852ca4fdca233145a58ae1ec94f0b0c01a2ed30`