Intel i7-8650U (Kaby Lake), Intel UHD 620, 31 GiB RAM, Omarchy 4.0.4, kernel 7.2.5-3-omarchy

`omarchy-windows-vm launch` succeeds exactly once after install, then fails forever after:

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

The privileged step exits 1 with **no output at all** on stdout or stderr, and never reaches Docker.

### Root cause

`prepare_caller_mounts` hardens both bind-mount sources, then compares the resulting mode with an exact string match (`omarchy-windows-vm:583`):

```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
```

Two problems compound:

1. `stat -c %a` includes the setuid/setgid/sticky bits in the octal mode, and **`chmod 0700` does not clear setgid on a directory**. A source dir at mode `2700` therefore can never satisfy `== 700`, no matter how many times you chmod it:
   ```
   $ stat -c %a ~/Windows        # 2700
   $ chmod 0700 ~/Windows
   $ stat -c %a ~/Windows        # 2700  <- still not "700"
   ```
2. `dockurr/windows` chmods the shared mount (`/shared`) on every container start. Measured: `700` → `2777`.

Since `__priv_up_wait` calls `assert_mounts_safe` **before** `dc up -d`, the ordering traps it:

1. First launch — `$HOME/Windows` is `700`, check passes, container starts, dockurr sets `2777`, RDP connects
2. RDP closes — `priv down` runs, container removed
3. Every later launch — `$HOME/Windows` is `2700`/`2777`, check fails silently and Docker is never reached

### Reproduction

```bash
chmod 2700 ~/Windows
pkexec /usr/bin/omarchy-windows-vm __priv up_wait   # exits 1, prints nothing
```

### Suggested fix

Clear setgid explicitly before comparing:

```bash
chmod g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" 2>/dev/null || true
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {...}
```

Verified against 4.0.4 by driving the functions directly: with that one-line addition `prepare_caller_mounts` succeeds and normalizes the source back to `700` (tested from both `2700` and `2777`); unpatched, the same call fails silently from both.

Note that masking the comparison instead (`(( 8#$mode & 0777 )) == 700`) would let `2700` pass but would still admit dockurr's `2777`, leaving the shared folder setgid and world-writable — so clearing the bit is the better fix.

### Two related problems worth addressing at the same time

1. **The silent `return 1`.** Every other refusal in `assert_mounts_safe` / `prepare_caller_mounts` writes a diagnostic to stderr. This path is the only one that returns 1 with no message, which is what made this hard to find — it presents as an authorization or Docker failure rather than a permissions check.

2. **`2777` on the shared folder.** dockurr leaves `$HOME/Windows` setgid and world-writable for as long as the container runs, which is a local hygiene concern independent of the above.

### Workaround in the meantime

```bash
chmod g-s ~/Windows && chmod 0700 ~/Windows && omarchy-windows-vm launch
```

No `sudo` needed — the directory is owned by the invoking user. Both calls are required: `chmod 0700` alone does not clear setgid, and GNU chmod rejects combined forms like `chmod 0700,g-s`.