## System details

- CPU: AMD Ryzen 5 PRO 8540U with Radeon 740M Graphics
- GPU: AMD HawkPoint2 integrated graphics
- Omarchy: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- Filesystem containing `$HOME/Windows`: Btrfs
- Windows VM image: `dockurr/windows`

## What's wrong?

The Windows VM can fail to launch after it has previously run and the host has been restarted.

The Polkit authorization succeeds, but the command exits with only:

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

The shared directory's mode changes after the VM runs. I observed both `2700` and `2777`:

```bash
stat -c '%a %A %n' "$HOME/Windows"
```

```text
2700 drwx--S--- /home/<user>/Windows
```

and later:

```text
2777 drwxrwsrwx /home/<user>/Windows
```

After reboot, the protected bind mounts need to be recreated. The launch then fails while validating the shared mount because its mode is not exactly `700`.

### Steps to reproduce

1. Install and launch the Windows VM.
2. Let Windows start successfully.
3. Close/stop the VM and restart the host.
4. Check the directory mode with `stat -c '%a %A %n' "$HOME/Windows"`.
5. Run `omarchy windows vm launch`.
6. Complete the Polkit authorization prompt.
7. The launch fails with the generic error above.
8. Explicitly clear setgid and restore the permissions:

   ```bash
   chmod g-s "$HOME/Windows"
   chmod 0700 "$HOME/Windows"
   ```

9. Run `omarchy windows vm launch` again. The VM starts successfully.

The problem recurs once the VM changes the directory permissions again.

## Suspected cause

In `omarchy-windows-vm`, `prepare_caller_mounts()` attempts to normalize both source directories with:

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

It then requires the mode to be exactly `700`:

```bash
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  return 1
fi
```

GNU `chmod` preserves the setgid bit on directories when a numeric mode is specified unless the special bit is explicitly cleared. Therefore `chmod 0700` can leave this directory as `2700`. The following exact-mode check returns failure without printing a diagnostic, producing only the generic launcher error.

The same pattern also exists in `prepare_user_mount_sources()`.

## Suggested fix

Explicitly clear setgid while normalizing the directory, for example:

```bash
chmod g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" &&
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
```

It would also help to print the actual and expected modes before returning from the exact-mode validation.