## Summary

If either bind source for the Windows VM (`~/.windows` or `~/Windows`) has the setgid bit set, **every** `omarchy windows vm launch` fails immediately with the generic `❌ Failed to start Windows VM!` and no diagnostic output. Docker is never invoked at all.

The cause is in `prepare_caller_mounts`: it hardens both sources with `chmod 0700`, but **`chmod` with a numeric mode does not clear setuid/setgid on a directory**. It then reads the mode back, sees `2700`, fails its own `!= 700` check, and returns 1 through a branch that prints nothing.

The hardening step is a no-op against the exact condition the very next check rejects.

## Environment

| | |
|---|---|
| Omarchy | 4.0.3-1 |
| Kernel | 7.2.3-arch1-3 |
| CPU | AMD Ryzen 7 5800X3D |
| GPU | NVIDIA RTX 4070 (AD104) |
| `/home` filesystem | btrfs (`subvol=/@home`, no `grpid`) |
| coreutils | chmod (GNU coreutils) 9.11 |
| bash | 5.3.15(1)-release |
| docker / docker-compose | 1:29.7.2-1 / 5.5.1-1 |

## Steps to reproduce

```bash
chmod g+s ~/Windows        # mode becomes 2700
omarchy windows vm launch
```

Result:

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

Polkit authorization succeeds, `/run/lock/omarchy-windows-vm` is created, and the helper returns immediately. `docker inspect omarchy-windows` shows the container state completely untouched — no new `StartedAt`, no new log lines. The 2-minute readiness poll in `__priv_up_wait` is never reached.

Expected: the launch either succeeds, or fails with a message naming the problem.

## Root cause

`/usr/share/omarchy/bin/omarchy-windows-vm`, `prepare_caller_mounts`, lines 583-595:

```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          # <-- silent
fi
```

From `man chmod` (GNU coreutils):

> For directories chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like `u+s` and `g-s`. To clear these bits for directories with a numeric mode requires an additional leading zero like `00755`, leading minus like `-6000`, or leading equals like `=755`.

`0700` has one leading zero, which is not enough — `00700` is required. So `chmod` exits 0 without clearing the bit, `stat -Lc '%a'` returns `2700`, and the comparison against the bare string `700` fails.

Verified on a throwaway directory on the same btrfs subvolume, both through a direct path and through `/proc/self/fd` exactly as the script does:

```
start:        2700 drwx--S---
after chmod 0700 (direct):   2700 drwx--S---
after chmod 0700 (via fd):   2700 drwx--S---
after chmod g-s:              700 drwx------
```

This is coreutils semantics, not a btrfs quirk — `/home` is mounted without `grpid`/`bsdgroups`.

## Why it is hard to diagnose

1. The failing branch is one of the few in this area with no `echo ... >&2`. `assert_mounts_safe` has six bail-outs that each name their reason; this one returns bare `1`, and the message at line 891 (`refusing an unsafe VM mount anchor`) is only reached via `mounts_ready`, not via `prepare_caller_mounts`.
2. The launcher is normally started from `windows-vm.desktop` through `gtk-launch`, so even if there were output it would go nowhere. Running `omarchy windows vm launch` from a terminal produces no extra detail either, because there is nothing to print.
3. `omarchy windows vm status` reports `stopped (status: exited)` with a stale, clean `exit=0` from the previous successful session, which points the investigation at the guest rather than at the host-side gate.

## Suggested fix

Clear the bits explicitly, and give the branch a message:

```bash
chmod 00700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
  ...
}
...
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  echo "omarchy-windows-vm: could not restrict VM data directories to mode 700 (storage=$storage_mode shared=$shared_mode)" >&2
  ...
fi
```

`chmod g-s,u-s,0700` or `=700` would work equally well. A message on that branch is worth having regardless of the mode fix, since it is currently the only silent failure path in an otherwise well-instrumented gate.

## Workaround

```bash
chmod g-s ~/Windows ~/.windows
```

## How the directory got the bit

Unclear — `~` itself is `700` with no setgid, so it was not inherited. Worth noting that whatever set it, the VM then became permanently unlaunchable with no way for the user to find out why.