### System details

- CPU: AMD Ryzen 7 5700X3D
- GPU: AMD Radeon RX 9070/9070 XT/9070 GRE (Navi 48)
- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- GNU coreutils: 9.11

### What's wrong?

The Windows VM launcher exits immediately after successful polkit authorization and shows the critical notification:

> Windows VM — Failed to start Windows VM

This happens when either VM source directory has a set-ID bit in addition to the expected private permissions. In my case, `~/Windows` had mode `2700` (`drwx--S---`). The VM data itself and Docker were healthy.

### Steps to reproduce

1. Install/configure the Omarchy Windows VM.
2. Add the set-group-ID bit to the shared directory:

   ```bash
   chmod g+s ~/Windows
   stat -c '%a' ~/Windows  # 2700
   ```

3. Launch the VM from the menu or run `omarchy-windows-vm launch`.
4. Approve the polkit prompt.

The launcher fails before starting the Docker container.

The underlying `chmod` behavior can also be reproduced without the VM:

```bash
dir=$(mktemp -d)
chmod 2700 "$dir"
chmod 0700 "$dir"
stat -c '%a' "$dir"       # still 2700
chmod a-s,u=rwx,go= "$dir"
stat -c '%a' "$dir"       # 700
rmdir "$dir"
```

### Root cause

`prepare_caller_mounts()` attempts to normalize both directories and then requires their modes to equal exactly `700`:

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

storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd")
shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd")
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  return 1
fi
```

GNU `chmod` deliberately preserves set-user-ID and set-group-ID bits on directories when a plain numeric mode such as `0700` is used. Therefore the normalization reports success but leaves `2700` unchanged, and the exact-mode check immediately rejects it.

Reference: https://www.gnu.org/software/coreutils/manual/html_node/Operator-Numeric-Modes.html

### Expected behavior

The privacy normalization should explicitly clear special bits so that the following exact-mode safety check can succeed.

### Suggested fix

Use a symbolic mode that clears set-ID bits explicitly:

```diff
-  chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
+  chmod a-s,u=rwx,go= -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
```

`chmod =700` also clears them with GNU coreutils, but the symbolic form makes the security intent explicit. I verified locally that it changes both `2700` and `700` inputs to exactly `700`, after which the protected bind-mount checks pass.