### Description

`omarchy-windows-vm launch` reliably fails to (re)start the Windows VM after it has been run once and stopped, with only a generic error:

```
❌ Failed to start Windows VM!
   Try checking: omarchy-windows-vm status
```

### Root cause

While the VM is running, the Samba service inside the `dockurr/windows` container (which serves the bind-mounted `/shared` folder to the guest) changes the **host-side** permissions of the mounted source directory (`~/Windows`) — e.g. from `0700` to `2777` (setgid + world read/write/execute). This persists after `omarchy-windows-vm stop`.

On the next `launch`, `assert_mounts_safe` → `prepare_caller_mounts` is supposed to reset this:

```bash
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ... }
storage_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$storage_fd" 2>/dev/null) || storage_mode=""
shared_mode=$(stat -Lc '%a' "/proc/$BASHPID/fd/$shared_fd" 2>/dev/null) || shared_mode=""
if [[ $storage_mode != 700 || $shared_mode != 700 ]]; then
  ...
  return 1
fi
```

On my system, this numeric `chmod 0700` does **not** reliably clear an already-set setgid bit on the `shared` directory (traced with `bash -x` through the real elevated `pkexec ... __priv up` invocation — the `chmod 0700` call runs, exits 0, but the immediately-following `stat` still reports `2700`/`2777`). Because the verification check right after requires exact mode `700`, `prepare_caller_mounts` returns 1, `assert_mounts_safe` fails, and the whole `launch`/`up_wait` aborts silently (no diagnostic reaches the top-level script beyond the generic "Failed to start" message).

Switching to an explicit **symbolic** chmod that directly targets the special bits reliably clears them every time:

```bash
chmod u=rwx,go=,u-s,g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"
```

I applied this one-line change locally to `/usr/bin/omarchy-windows-vm` and confirmed the full reproduce/fix cycle:
1. Launch VM, let it run a bit → `~/Windows` drifts to `2777` (confirmed via `stat` while the container is up).
2. `omarchy-windows-vm stop` → drift persists (`2777`).
3. `omarchy-windows-vm launch` with the **unpatched** script → fails with the generic error above, mounts never come up.
4. Same launch with the **patched** `chmod` line → succeeds every time, no manual intervention needed.

### Steps to reproduce

1. `omarchy-windows-vm install` and let the VM boot once.
2. Connect (or just let it run) so Samba touches `/shared`.
3. `omarchy-windows-vm stop`
4. `omarchy-windows-vm launch` → fails.
5. Check `stat -c '%a' ~/Windows` → shows something other than `700` (e.g. `2777`) instead of the expected `700`.

### Expected behavior

`launch` should reliably succeed after a previous `stop`, regardless of what permissions the Samba service inside the guest left on the shared host directory.

### Suggested fix

In `prepare_caller_mounts` (around the "Privacy is an explicit preflight step..." comment), replace the numeric chmod with an explicit symbolic one that unambiguously clears the special bits:

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

### Environment

- Omarchy: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- Docker: 29.7.2
- Docker Compose: 5.5.0
- Filesystem: btrfs (home on `/@home` subvolume)
- chmod: GNU coreutils 9.11