**Title:** Windows VM: `omarchy-windows-vm launch` fails silently ("Failed to start Windows VM") when the shared-folder anchor has the setgid bit set

**System details:** Intel Core i7-8850H, Intel UHD Graphics 630, Omarchy 4.0.2-1

**What's wrong?**

After installing and running the Windows VM (`omarchy-windows-vm install` → `omarchy-windows-vm launch`), a *later* `omarchy-windows-vm launch` can start failing with only:

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

`omarchy-windows-vm status` shows the container is still `RUNNING`, and `docker logs` confirms Windows booted fine — so this isn't actually a VM start failure, it's the privileged `up_wait` helper aborting before it even touches Docker.

**Root cause**

`prepare_caller_mounts()` requires both mount-anchor directories to be exactly mode `700`:

```bash
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
```

The `shared` anchor (bind-mounted into the guest as `/shared` for the Samba share) ends up with mode `2700` (setgid bit set) after normal use from inside the Windows guest — this looks like legitimate behavior from the guest's SMB client/server touching the folder, not tampering. Once that happens, every subsequent `up_wait`/`up` call fails this strict `== 700` comparison and aborts.

The bigger issue: **none of the failure paths here print anything to stderr**, so the wrapper's `launch_windows()` just prints the generic "Failed to start Windows VM!" with zero indication of *why*. Tracing it required running `pkexec bash -x /usr/bin/omarchy-windows-vm __priv up_wait` to find the actual `[[ 2700 != 700 ]]` comparison.

**Steps to reproduce**

1. `omarchy-windows-vm install` and let Windows finish setting up.
2. Use the VM for a while (browse the `shared`/`Windows` folder from inside the guest) so the setgid bit gets set on the host-side shared anchor.
3. Close RDP (VM auto-stops), then `omarchy-windows-vm launch` again.
4. Observe the opaque "Failed to start Windows VM!" message even though nothing is actually wrong with Docker/the container.

**Workaround**

```
chmod g-s /home/<user>/Windows   # or wherever the shared folder points
omarchy-windows-vm launch
```

(Path found via `findmnt -T /var/lib/omarchy/windows/mounts/users/<uid>/shared`.)

**Suggested fix**

Either:
- mask off the setgid/setuid/sticky bits before comparing (`mode=$(( 8#$mode & 0777 ))` or compare against a pattern that ignores the leading digit) instead of a strict `== 700`/`== 700`, since the guest's own Samba usage legitimately sets it, or
- have `prepare_caller_mounts` re-clear the bit itself (it already does `chmod 0700` on both fds earlier in the function — but the *later* comparison still reads the fd's mode via `stat`, and that chmod apparently doesn't stick for the `shared` fd, worth double-checking why), and/or
- at minimum, echo the specific failing check to stderr so `launch_windows` can surface something more actionable than "Failed to start Windows VM!".