## Summary

`omarchy-windows-vm launch` fails (silently, rc=1) on every launch *after the VM has been started once*, because the shared-folder source `~/Windows` carries the **setgid bit** that the script's privacy check rejects.

## Environment

- Omarchy **4.0.4-1** (Arch, kernel `7.2.5-3-omarchy`)
- Docker **29.7.2**, dockur/windows **v6.05**
- Default `omarchy windows-vm install` flow

## Reproduction

1. `omarchy windows-vm install` (creates `~/.windows` disk and `~/Windows` shared dir)
2. `omarchy windows-vm launch` → works; the VM boots.
3. Stop the VM (`omarchy windows-vm stop` or auto-stop on RDP close).
4. After a reboot, `omarchy windows-vm launch` again → **fails**: pkexec `__priv up_wait` exits 1 with no error message; `omarchy windows-vm status` reports `exited`; the container is never (re)started.

## Root cause

Two parts:

1. **dockur/windows re-modes the shared folder on every container start.** `/run/samba.sh` runs `chmod 2777 "$dir"` on the `/shared` mount (samba.sh:139 / :159). Since `/shared` is a bind mount of the host's per-user shared dir (`/var/lib/omarchy/windows/mounts/users/1000/shared` → `~/Windows`), this reaches the host inode, leaving `~/Windows` at mode `2777`.

2. **`omarchy-windows-vm` cannot meaningfully clear it.** `prepare_caller_mounts()` hardens the sources with:

   ```bash
   chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
   ```
   and then requires the result to be exactly `0700` (`[[ $shared_mode != 700 ]] → return 1`).

   GNU coreutils `chmod` **preserves** the set-group-ID (and set-user-ID) bits of a *directory* with a plain numeric mode — to clear them you must use `g-s`, `=700`, or a leading-zero octal like `00700`. So `chmod 0700` turns dockur's `2777` into `2700`, the `mode == 700` check fails, and `assert_mounts_safe` aborts before `docker compose up`.

   A `bash -x` trace of the failed run shows exactly this termination:
   ```
   chmod 0700 -- /proc/11985/fd/11 /proc/11985/fd/12
   storage_mode=700
   shared_mode=2700
   [[ 2700 != 700 ]]  → return 1
   ```

This repeats deterministically: first-boot works, every later launch fails, and a one-time `chmod 00700 ~/Windows` is *not* persistent because dockur re-sets `2777` at each container start.

## Expected behavior

The VM should start reliably across launches/reboots, and the shared dir should not force-depend on `~/Windows` having a stray special bit that dockur keeps re-adding.

## Suggested fix

In `prepare_caller_mounts()` (and the analogous hardening in the install path, e.g. `chmod 0700 -- "$storage" "$shared"`), clear the special bits explicitly, e.g.:

```bash
chmod 00700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
```

(the leading-zero octal clears setgid on directories across GNU coreutils versions), or `chmod g-s,0700 ...` for clarity.

## Workaround in use meanwhile

A user systemd path/service unit watches the shared dir and re-applies `chmod 00700` whenever its mode changes (and once at login). This keeps the user's shared folder at `0700`, but it is a stopgap — the hardened, root-owned command should clear the bit itself. (Also note: while dockur is free to chmod `/shared` to `2777` inside the container, the host-side dir ends up world-writable; clearing to `0700` is the intended posture.)