### Summary

`omarchy-windows-vm launch` fails with `❌ Failed to start Windows VM!` and **no other output**, on a VM that is healthy and reachable over RDP. `omarchy-windows-vm status` simultaneously reports `RUNNING`.

The cause is a mode check in `prepare_caller_mounts` that the script itself cannot satisfy, and the `dockurr/windows` container re-creates the triggering condition on **every** start — so each successful start breaks the *next* launch.

### Environment

- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2, GNU coreutils 9.11, Docker Compose 5.5.0
- Intel Core Ultra 9 275HX, Intel Arrow Lake-S + NVIDIA RTX 5070 Mobile

### Root cause

`bin/omarchy-windows-vm:583-593`, inside `prepare_caller_mounts`:

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

The container sets `/shared` — bind-mounted from `~/Windows` — to `2777` on every start. **GNU chmod preserves setuid/setgid on directories when given an octal mode**, so the script's own normalisation cannot clear it:

```
start:        2777
after 0700:   2700   <- the script's chmod, mode "retained as 2700"
after g-s:    700
```

`stat -Lc '%a'` therefore returns `2700`, the comparison against the literal `700` fails, and the function returns 1. The callers at `:859` and `:888` propagate the bare `return 1`, and `launch_windows` prints only `❌ Failed to start Windows VM!`.

### Why this is unusually hard to diagnose

- **The failure is silent.** Every other refusal in `assert_mounts_safe` prints a reason to stderr; this branch prints nothing.
- **`status` still says RUNNING**, because `__priv_status` does not go through the mount checks.
- **It is self-perpetuating.** Clearing the bit by hand fixes exactly one launch; the next container start restores `2777`. Observed here: cleared 23:30, VM started 23:44, broken again by 23:47.
- **Through the desktop launcher the stderr is discarded** (`gtk-launch`), so even the branches that do print a reason surface nothing to the user.
- `chmod 0700 ~/Windows` — the obvious manual fix — reports `mode retained as 2700` and changes nothing, which sends you looking in the wrong place.

### Steps to reproduce

```bash
chmod 2777 ~/Windows        # what the container does on every start
omarchy-windows-vm launch   # ❌ Failed to start Windows VM!   (no other output)
omarchy-windows-vm status   # Windows VM Status: RUNNING
```

### Workaround

```bash
chmod 0700 ~/Windows && chmod g-s ~/Windows   # both calls are required
```

### Suggested fix

1. Normalise the mode in a way that actually clears the high bits — `chmod u=rwx,go=,g-s`, or `chmod 0700` followed by `chmod g-s` — or compare against the permission bits only rather than the literal string `700`.
2. Give this branch a message, matching the other refusals in `assert_mounts_safe`, e.g. `omarchy-windows-vm: refusing VM mount source with unexpected mode $shared_mode`. The silent `return 1` is what turns a one-line fix into a long debugging session.