### What happened

`omarchy windows vm launch` fails with no diagnostic beyond:

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

`omarchy windows vm status` reports the container normally. Running the
privileged action directly exits 1 and prints **nothing at all**:

```
$ pkexec /usr/share/omarchy/bin/omarchy-windows-vm __priv up_wait
rc=1
```

### Root cause

`prepare_caller_mounts` hardens both bind sources and then asserts the result
(`bin/omarchy-windows-vm`, lines 583-594 on `main`):

```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` deliberately preserves setuid/setgid on directories when given a
numeric mode.** So if `~/Windows` is `2700`, the `chmod 0700` succeeds, the bit
survives, `stat -Lc '%a'` returns `2700`, the comparison against `700` fails,
and the function returns 1 with no message. Minimal proof (coreutils 9.11):

```
$ mkdir t && chmod 2700 t
$ stat -c %a t                 # 2700
$ chmod 0700 t && stat -c %a t # 2700   <-- unchanged
$ chmod g-s t  && stat -c %a t # 700
```

### How the directory gets setgid in the first place

The `dockurr/windows` image sets it itself. `/run/samba.sh` runs `chmod 2777`
on the shared folder whenever it finds it empty at VM start:

```bash
# Keep newly created content in the shared group through the setgid bit.
if ! chmod 2777 "$dir"; then
```

Those are the only two `chmod` calls the image makes against the share (lines
139 and 159), both gated on the directory being empty. So the ordinary
lifecycle is: `omarchy windows vm install` creates an empty `~/Windows` ->
first boot stamps it `2777` -> a later Omarchy run knocks it down to `2700` ->
the setgid bit is now permanent, and every subsequent launch fails silently.

This is self-inflicted by the normal install path, not an exotic local state.

### Steps to reproduce

```bash
chmod g+s ~/Windows
omarchy windows vm launch     # fails with no reason given
```

### Expected

Either normalize the bit (`chmod 0700` cannot; `chmod g-s` or `chmod u=rwx,go=,g-s` can),
or accept it — the setgid bit on a `0700` directory grants nothing, since the
group has no permissions at all.

### Suggested fix

Two independent problems, both small:

1. **Clear the bit properly.** Follow the `chmod 0700` with an explicit
   `chmod g-s,u-s`, or compare only the low three bits
   (`(( 8#$storage_mode & 0777 ))`) instead of a string equality against `700`.
   Both `prepare_caller_mounts` and the sibling `chmod 0700` at lines 1018 and
   1061 have the same blind spot.

2. **Say something on failure.** Every other rejection in `assert_mounts_safe`
   prints a reason ("refusing an untrusted compose file", "refusing unexpected
   host paths in the compose", ...). This path and the bare
   `prepare_caller_mounts || return 1` calls are silent, which makes the
   failure very hard to trace — the launch aborts with only the generic
   "Failed to start Windows VM!".

### Workaround

```bash
chmod g-s ~/Windows    # note: chmod 0700 ~/Windows will NOT work
```

### System

- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- AMD Ryzen 7 3700X / NVIDIA GeForce RTX 3060 (GA106)
- Docker 29.7.2, image `dockurr/windows`
- GNU coreutils 9.11