## What happened

A fresh `omarchy windows vm install` completed successfully — Windows 11 installed, the `omarchy-windows` container is running, and the guest answers RDP on `127.0.0.1:3389`. But `omarchy windows vm launch` fails every time:

```
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```

...while `omarchy windows vm status` simultaneously reports **RUNNING**. The VM is fine; the launch preflight is rejecting it.

## Root cause

`launch` → `priv up_wait` → `__priv_up_wait` → `assert_mounts_safe` → `prepare_caller_mounts`, which runs a privacy preflight (`omarchy-windows-vm`, 4.0.2-1):

```bash
583  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
588  storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd" 2>/dev/null) || storage_mode=""
589  shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd" 2>/dev/null) || shared_mode=""
590  if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
```

Two things combine:

1. The `dockurr/windows` container creates the `/shared` mount source (`~/Windows`) **setgid** — it was `drwxrwsrwx` (2777) here after install.
2. **GNU `chmod` does not clear setuid/setgid on a directory when given a numeric mode**, including a 4-digit one. `chmod 0700` on a 2777 directory yields **2700**, not 700.

So line 588-589 read back `2700`, the string comparison on line 590 fails, `prepare_caller_mounts` returns 1, and `launch` reports the VM failed to start.

Minimal repro of the `chmod` half (GNU coreutils 9.11, btrfs):

```console
$ mkdir d && chmod 2777 d && chmod 0700 d && stat -c %a d
2700
```

## Steps to reproduce

1. `omarchy windows vm install`, let Windows 11 finish installing.
2. `omarchy windows vm status` → **RUNNING**.
3. `omarchy windows vm launch` → **"Failed to start Windows VM!"**
4. `stat -Lc '%a' ~/Windows` → **`2700`** (while `~/.windows` is a clean `700`).

The privileged half does run — `journalctl` confirms polkit authorized `omarchy-windows-vm __priv up_wait` as root immediately before the failure, so this is not an authorization problem.

## Expected

`launch` connects, since the container is up and the guest is serving RDP.

## Workaround

```console
$ chmod g-s ~/Windows
```

`launch` then works. This will recur whenever the container re-applies setgid to the share.

## Suggested fix

Either strip the bits explicitly — symbolic modes *do* clear them:

```bash
chmod u=rwx,go=,ug-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
```

or compare only the permission bits, so no setuid/setgid/sticky bit can trip the check:

```bash
(( (8#$storage_mode & 0777) == 0700 && (8#$shared_mode & 0777) == 0700 )) || { ... }
```

Verified locally:

| command | result on a 2777 dir |
|---|---|
| `chmod 0700` | `2700` ✗ (current behavior) |
| `chmod u=rwx,go=` | `2700` ✗ |
| `chmod u=rwx,go=,ug-s` | `700` ✓ |

Lines 1018 (`chmod 0700 -- "$storage" "$shared"`) and 1061 (`chmod 0700 "$dir"`) carry the same exposure.

## System

- Omarchy **4.0.2-1** (stable channel)
- Kernel 7.1.9-arch1-2
- CPU Intel Core Ultra 7 255H · GPU Intel Arrow Lake-P (Arc Pro 130T/140T)
- Docker 29.7.2 · `dockurr/windows` · Windows 11 25H2
- GNU coreutils 9.11 · home on btrfs

(`omarchy debug --no-sudo --print` referenced in the contributing docs doesn't exist in 4.0.2 — `Unknown Omarchy command` — so the above was collected by hand.)