## What happened

`omarchy windows vm launch` (and `omarchy-windows-vm launch`) fails with just:

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

No further diagnostic output, and `omarchy-windows-vm status` just reports "container not found" — the Docker container is never even created, so there's nothing in `docker logs` or the Docker daemon journal to point at.

## Root cause

In `omarchy-windows-vm`, `prepare_caller_mounts()` runs a "privacy preflight" on the host source directories before binding them into the container:

```sh
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$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
  ...
  return 1
fi
```

Per `man chmod`:

> For directories chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise. ... To clear these bits for directories with a numeric mode requires an additional leading zero like `00755`.

`chmod 0700` has only a single leading zero, so on a directory that has the setgid bit set, GNU chmod silently **preserves** it instead of clearing it. I confirmed this directly:

```
$ chmod -v 0700 ~/Windows
mode of '/home/x/Windows' retained as 2700 (rwx--S---)

$ chmod g-s ~/Windows
$ stat -c '%a' ~/Windows
700
```

Because the chmod silently no-ops, the very next line's self-check (`$shared_mode != 700`) correctly notices the mode is still `2700`, and `prepare_caller_mounts` returns 1. That failure propagates silently (no `echo`) up through `assert_mounts_safe` → `mounts_ready` → `__priv_up_wait`, so `launch_windows` only ever sees a bare non-zero return and prints the generic "Failed to start Windows VM!" with no indication of what actually failed.

This also makes the bug **recurring**: once it happens once with a setgid'd `~/Windows` (or `~/.windows`), *every subsequent launch* hits the same silent failure, since the chmod never actually fixes it.

## Steps to reproduce

1. Have a Windows VM share folder (`~/Windows`) with the setgid bit set (`chmod g+s ~/Windows`) — this can happen from various normal directory-creation paths (inherited from a parent dir, etc).
2. Run `omarchy-windows-vm launch`.
3. Observe "❌ Failed to start Windows VM!" with no further detail, and no container ever created.

## Expected behavior

Either:
- The chmod should use `00700` (double leading zero) so it actually clears setgid/setuid/sticky on directories as intended, or
- If the preflight check intentionally wants to *refuse* starting rather than force-fix permissions, it should at least print a clear error (e.g. `omarchy-windows-vm: refusing: ~/Windows has unexpected permission bits (2700), run 'chmod g-s ~/Windows' to continue`) instead of a silent `return 1` with a generic downstream message.

## Workaround

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

...which has to be repeated before every launch if it keeps getting re-applied.

## System info

- Omarchy version: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- CPU: 13th Gen Intel(R) Core(TM) i5-13400F