## What happened

After the Windows VM has been started once, every subsequent `omarchy-windows-vm launch` (or `omarchy windows vm launch`) fails immediately with:

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

`omarchy-windows-vm status` still shows the container as absent/stopped, and there is no polkit prompt — the command fails before Docker is even asked to bring the container up.

## Expected

`omarchy-windows-vm launch` should keep working across repeated stop/start cycles, the same way it works the very first time (right after `omarchy-windows-vm install`).

## Root cause

1. The `dockurr/windows` container (used as the VM backend) sets the host-side bind-mounted `~/Windows` "shared" folder to mode `2777` (setgid + world-writable) on every container boot, so its internal Samba service can write into it regardless of host UID.
2. `omarchy-windows-vm`'s `prepare_user_mount_sources()` (and the general convention used elsewhere in the script) resets ownership/permissions with a **4-digit numeric** `chmod 0700 -- "$storage" "$shared"`.
3. Per documented GNU `chmod` behavior (`man chmod`, "SETUID AND SETGID BITS"): *"For directories chmod preserves set-user-ID and set-group-ID bits unless you explicitly specify otherwise... numeric mode requires an additional leading zero like 00755, leading minus like -6000, or leading equals like =755."* A plain `0700` does **not** clear a pre-existing setgid bit on a directory — only `00700`, `=700`, `-2000`, or the symbolic form `g-s` do.
4. So once the container has booted and set `~/Windows` to `2777`, `chmod 0700` on it is silently a no-op for the setgid bit, and the directory permanently sits at mode `2700` instead of `700`.
5. `mounted_leaf_matches()` in `omarchy-windows-vm` does a strict string comparison `[[ $mode == 700 ]]`, which now always fails against `2700`.
6. That makes `mounts_ready` (and therefore `assert_mounts_safe`) return false on every future `launch`/`up`/`up_wait`, permanently, until a human manually clears the bit.

## Steps to reproduce

```bash
omarchy-windows-vm install   # complete setup
omarchy-windows-vm launch    # works the first time, VM boots
# ... use/close the VM, VM auto-stops ...
omarchy-windows-vm launch    # fails every time from here on
```

Or minimally, reproduce just the permission bug directly:

```bash
mkdir -p /tmp/permtest
chmod 2777 /tmp/permtest
chmod -v 0700 /tmp/permtest
stat -c '%a' /tmp/permtest   # prints 2700, not 700
```

## Confirmed workaround

Manually clearing the setgid bit with a symbolic chmod restores the check to passing (until the VM boots again and resets it):

```bash
chmod g-s ~/Windows
omarchy-windows-vm launch    # now succeeds
```

## Suggested fix

In `/usr/share/omarchy/bin/omarchy-windows-vm`, replace the numeric `chmod 0700 -- "$storage" "$shared"` calls (and any other directory chmod meant to clear special bits) with a form that actually clears setgid/setuid, e.g. `chmod 00700` (5-digit), `chmod =700`, or `chmod -s,0700`. Alternatively/additionally, harden `mounted_leaf_matches()` to strip the setgid/setuid bits before comparing (or to actively re-chmod with a clearing form) rather than doing a strict `== 700` string match against `stat -c '%a'`, which includes the special-bits digit whenever it's nonzero.

## System details

- Omarchy version: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- CPU: AMD Ryzen 5 PRO 5650U with Radeon Graphics
- GPU: AMD Radeon Vega (Cezanne, integrated)
- Docker: 29.7.2
- Docker Compose: 5.5.1
- coreutils (chmod): 9.11