## What happened

`omarchy windows vm launch` (and the "Windows" app launcher entry) fails with:

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

No further diagnostic is printed anywhere (not to the terminal, not in `journalctl`), and `omarchy-windows-vm status` just reports "Windows VM container not found." `docker ps -a` confirms the `omarchy-windows` container is never even created — the failure happens before `docker compose up` runs.

## Root cause

In `omarchy-windows-vm`, `prepare_caller_mounts()` bind-mounts `~/.windows` and `~/Windows` into the protected runtime anchors, then tightens their permissions and verifies the result:

```sh
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
  ...
  return 1
fi
```

If either source directory has the setgid bit set (`2700` instead of `700` — easy to end up with, e.g. inherited from a parent directory's setgid bit), this `chmod 0700` call **silently does not clear it**, even when run as root. That's documented GNU coreutils behavior, not a bug in chmod itself:

> For directories chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise ... To clear these bits for directories with a numeric mode requires an additional leading zero like `00755`, leading minus like `-6000`, or leading equals like `=755`.
(`man chmod`, SETUID AND SETGID BITS)

A 4-digit numeric mode like `0700` is *not* enough to force-clear an existing setgid bit on a directory — coreutils needs `00700` (5 digits) or a symbolic form like `chmod g-s`. So when `~/Windows` has setgid set, this chmod call is a silent no-op, the mode check above always sees `2700 != 700`, `prepare_caller_mounts` returns 1, `assert_mounts_safe` returns 1, and `dc up -d` never runs — with no error surfaced to the user anywhere in the call chain (the failure just bubbles up as a bare non-zero return with no `echo`).

I confirmed this directly:

```
$ stat -c '%a' ~/Windows
2700
$ pkexec bash -c 'chmod 0700 /home/jlharter/Windows; stat -c "%a" /home/jlharter/Windows'
2700          # unchanged, chmod exits 0
$ chmod g-s ~/Windows && stat -c '%a' ~/Windows
700           # this clears it
```

After manually clearing the setgid bit on `~/Windows`, `omarchy windows vm launch` worked immediately (container created, VM booted, RDP connected).

## Expected

`omarchy windows vm launch` should succeed regardless of whether `~/Windows` (or `~/.windows`) has the setgid bit set, and if the permission-hardening step genuinely fails, it should print an actionable error instead of a bare "Failed to start Windows VM!" with zero further diagnostics.

## Suggested fix

In `prepare_caller_mounts()`, force-clear setgid/setuid explicitly rather than relying on ambiguous numeric mode, e.g.:

```sh
chmod 00700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
# or
chmod u=rwx,go=,g-s,u-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
```

Also worth an `echo ... >&2` on the mode-mismatch branch so a future variant of this class of bug doesn't fail silently.

## Steps to reproduce

1. Have (or create) a Windows VM shared folder with the setgid bit set: `chmod g+s ~/Windows`
2. Run `omarchy windows vm launch`
3. Observe it fails with no diagnostic, and the container is never created

## System details

- Omarchy version: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- CPU: Intel Core Ultra 5 325
- GPU: Intel Panther Lake (xe driver)
- Filesystem: btrfs (`/home`)
- coreutils chmod: 9.11
- Docker: 29.7.2, Docker Compose 5.5.1