## omarchy-windows-vm fails silently when `~/Windows` carries the setgid bit

### Summary

`omarchy-windows-vm launch` (also via the "Windows" entry in the Quickshell menu /
`.desktop`, which runs the same command) fails to start the VM with no diagnostic
output when the user's shared-data directory `~/Windows` has mode `2700`
(setgid bit set) instead of `0700`. The user sees only the generic
"Failed to start Windows VM!" banner (or, from the menu, a critical
notification with no detail).

### What happened

1. `~/Windows` had mode `drwx--S---` (`2700`, setgid bit) — a legitimate state a
   directory can be in (e.g. created with a setgid parent).
2. `omarchy-windows-vm launch` ran: polkit authorization succeeds, the privileged
   `__priv up_wait` runs, and `assert_mounts_safe` → `prepare_caller_mounts`
   aborts at the exact-mode check below:
   - `chmod 0700 -- /proc/<pid>/fd/<storage_fd> /proc/<pid>/fd/<shared_fd>` **does
     not clear the setgid bit** when issued through the `/proc/<pid>/fd` path:
     storage read back `700`, shared read back `2700`.
   - `[[ $storage_mode != 700 || $shared_mode != 700 ]]` → true → `return 1`.
   - Every failure path back up to the CLI is silent:
     `__priv_up`/`__priv_up_wait` just `return 1`, the launch wrapper prints only
     the generic banner, and the container is never created. (Docker socket
     activation was never even triggered because the abort happens before the
     docker-compose call, which makes the failure easy to misread as "Docker
     not running".)

### Expected

- The VM starts, or at minimum the failing step emits the actual reason
  (e.g. `chmod 0700` on `~/Windows` did not stick → mode is `2700`), instead of
  failing silently.

### Workaround found on the affected machine

```bash
chmod g-s ~/Windows     # clears setgid → mode 0700
omarchy-windows-vm launch  # then works
```

### Steps to reproduce

1. `install -d -m 2700 ~/Windows` (or otherwise give the shared dir a setgid bit).
2. Configure the VM with `omarchy-windows-vm install` (or keep an existing install).
3. `omarchy-windows-vm launch` (authorize the polkit prompt).
4. Observe: no command output beyond the generic failure banner; no container is
   created; the VM never comes up. Manual binary reproduction with tracing:

```bash
# as root, with a valid compose in place:
mount_source=~/Windows
# prepare_caller_mounts() chmods via fd path then requires EXACT 0700:
#   chmod 0700 -- /proc/$BASHPID/fd/$shared_fd
#   stat -Lc %a ...            -> 2700  (setgid not cleared via fd path)
#   [[ 2700 != 700 ]]          -> abort, silent return 1
```

### Relevant code

`/usr/bin/omarchy-windows-vm`, `prepare_caller_mounts()`:

- https://github.com/basecamp/omarchy/blob/main/... (function in the packaged `omarchy-windows-vm` binary, ~line 583)
  - `chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"`
  - `if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then ... return 1; fi` (line ~590, no message emitted)

Two things worth fixing:
1. Robustness: a user-owned directory with a setgid bit should not be able to
   brick the mount preflight; either strip the bit with `chmod g-s`/`chmod 00700`
   in a way that actually sticks for the fd-based call, or relax the exact `== 700`
   check (e.g. compare masked bits / only enforce no world/group-write).
2. Observability: every `return 1` in the mount-preflight chain should emit a
   diagnostic (`echo ... >&2`) so `launch` reports the true cause.

### Environment

- Omarchy: `4.0.2-1`
- Kernel: `7.1.9-arch1-2` (Arch)
- Root filesystem for `~/Windows`: btrfs (`/dev/mapper/root[/@home]`, mounted at `/home`)
- Host: Hyprland/omarchy-shell (Quickshell menu launch path: `uwsm app -- gtk-launch windows-vm.desktop` → `Exec=uwsm app -- omarchy-windows-vm launch`)