### What happened

Every privileged `omarchy windows vm` operation (`remove`, `launch`, `stop`) fails
when either VM source directory — `~/.windows` or `~/Windows` — has the setgid bit
set. The failure is silent: the privileged helper returns 1 without printing a
reason, so the user only sees the generic wrapper message.

```
$ omarchy windows vm remove
Removing Windows VM...
❌ Windows VM removal stopped before user-side cleanup; inspect the VM data before retrying.
```

`~/Windows` was mode `2700` (`drwx--S---`). No other diagnostic is printed, so
there is nothing pointing at the mode as the cause.

### Root cause

`omarchy-windows-vm`, `prepare_caller_mounts()`:

```bash
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
  ...
}
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
```

GNU `chmod` does not clear setuid/setgid on a **directory** for a numeric mode of
four digits or fewer — `0700` leaves the setgid bit untouched. `stat -Lc '%a'`
then reports `2700`, the `!= 700` comparison fails, and the function returns 1.

The hardening step can therefore never satisfy its own postcondition, and the
mode check is unreachable-by-success for any setgid source directory.

This blocks every privileged path, since they all funnel through
`assert_mounts_safe` → `prepare_caller_mounts`:

- `__priv_remove()` — `assert_mounts_safe || return 1`
- `__priv_up()` — `assert_mounts_safe && dc up -d`
- `__priv_up_wait()` — `assert_mounts_safe || return 1`

Nothing is destroyed (the check runs before `dc down` and the `find -delete`), but
the VM becomes permanently un-launchable and un-removable through the CLI.

### Minimal reproduction

Independent of the VM — this is just the predicate:

```bash
d=$(mktemp -d); chmod 2700 "$d"
exec {fd}<"$d/."
chmod 0700 -- "/proc/$BASHPID/fd/$fd"
stat -Lc '%a' "/proc/$BASHPID/fd/$fd"   # prints 2700, expected 700
exec {fd}<&-
```

Observed on coreutils 9.11-2:

| chmod form  | resulting mode |
|-------------|----------------|
| `0700`      | `2700` ❌ |
| `u=rwx,go=` | `2700` ❌ |
| `00700`     | `700` ✅ |
| `g-s`       | `700` ✅ |

Note that the symbolic form `u=rwx,go=` does not clear it either — GNU chmod
preserves setuid/setgid on directories unless they are named explicitly.

End-to-end:

1. `chmod g+s ~/Windows` (or have a pre-existing setgid `~/Windows` before install —
   `install_windows` only creates the directory when it is absent:
   `[[ -e $shared || -L $shared ]] || install -d -m 0700 -- "$shared"`, so an
   existing setgid directory is adopted as-is)
2. `omarchy windows vm install`
3. `omarchy windows vm remove` → fails with the generic message above
4. `omarchy windows vm launch` → fails the same way

### Expected

Either the hardening actually clears the special bits, or the failure explains
itself. Both would be better.

### Suggested fix

```diff
-  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
+  # Numeric modes of four digits or fewer leave setuid/setgid on a directory
+  # alone; the fifth digit is what clears them, and the mode check below
+  # requires exactly 700.
+  chmod 00700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
```

and give the mode check a diagnostic so it is not silent:

```diff
   if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
+    echo "omarchy-windows-vm: VM source directories must be mode 700 (storage=$storage_mode shared=$shared_mode)" >&2
     exec {storage_fd}<&-
     exec {shared_fd}<&-
     return 1
   fi
```

The same silent-`return 1` pattern appears elsewhere in `prepare_caller_mounts`
and in `__priv_remove` (the `EXPECTED_STORAGE`/`EXPECTED_SHARED` equality checks),
which is why the wrapper's generic message is all the user ever gets. Worth a
pass, though the setgid case is the one that actually bites.

### Workaround

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

### System details

- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- coreutils 9.11-2
- Docker 29.7.2
- Hyprland 0.56.2
- CPU: Intel Core i9-10885H
- GPU: Intel CometLake-H GT2 [UHD Graphics] / NVIDIA TU104GLM [Quadro RTX 5000 Mobile / Max-Q]
- Sudoless Docker: not enabled (privileged actions go through pkexec)