## Summary

`omarchy-windows-vm launch` fails with "❌ Failed to start Windows VM!" (while `status` reports RUNNING) once `~/Windows` has the setgid bit set. The dockurr/windows container sets that bit itself on first boot, and omarchy's `chmod 0700` never clears it, so every subsequent launch is refused on both the docker-group and pkexec paths.

## System

- Omarchy 4.0.4-1
- CPU: Intel i9-12900KF, GPU: NVIDIA RTX 5080
- User is in the `docker` group (sudoless Docker), but the pkexec path fails the same way.

## Root cause

1. The dockurr/windows container's `/run/samba.sh` runs `chmod 2777 /shared` whenever the share is empty at container start ("Keep newly created content in the shared group through the setgid bit"). Through the bind mount that lands on `~/Windows`.
2. `bin/omarchy-windows-vm` hardens the sources with `chmod 0700` (`prepare_caller_mounts`, line 583; also 1018 and 1061). GNU chmod **preserves a directory's setuid/setgid bits** when given a 3- or 4-digit octal mode, so `2777` becomes `2700`, not `700`.
3. `mounted_leaf_matches` (line 518) and the post-chmod check in `prepare_caller_mounts` (line 590) require `$mode == 700` exactly. `2700` fails both:
   - user side: `mounts_ready` fails, so `priv` falls through to pkexec
   - root side: `prepare_caller_mounts` returns 1 after its own chmod, so `__priv_up_wait` fails silently
4. `launch_windows` prints the generic "Failed to start Windows VM!" and exits 1. `status` still says RUNNING because it only inspects the container.

## Reproduce

```bash
omarchy-windows-vm install          # with an empty ~/Windows
omarchy-windows-vm launch           # works; container chmods /shared to 2777
omarchy-windows-vm stop
stat -c %a ~/Windows                # 2777
omarchy-windows-vm launch           # ❌ Failed to start Windows VM!
stat -c %a ~/Windows                # 2700 — pkexec path ran chmod 0700, setgid survived
```

## Expected

Launch should succeed, or at least say why it refused. Nothing in the failure output points at `~/Windows` permissions.

## Suggested fix

Clear the special bits explicitly wherever the script hardens the sources, e.g.

```bash
chmod u=rwx,go=,g-s -- "$storage" "$shared"    # or chmod 00700
```

at lines 583, 1018 and 1061, and/or have `mounted_leaf_matches` compare `%a` masked to the permission bits. A `refusing an unsafe VM mount anchor` message reaching the user instead of the generic failure line would also have made this diagnosable.

## Workaround

```bash
chmod g-s ~/Windows
touch ~/Windows/.keep   # non-empty share: container skips its chmod 2777 on the next start
```