### System details

omarchy 4.0.2-1

### What's wrong?

## Summary

`omarchy windows vm launch` fails with `❌ Failed to start Windows VM!` even when the Windows
container/VM is otherwise healthy and reports `Windows started successfully`. The failure is
caused by a mode-check in `prepare_caller_mounts()` (/usr/bin/omarchy-windows-vm): the source
directories for the `/storage` and `/shared` bind mounts are `chmod`'d through a pinned
`/proc/$BASHPID/fd/N` handle, and on the reporter's system (btrfs) that form silently fails to
clear a pre-existing **setgid** bit. The dir stays at mode `2700`, the guard
`[[ $mode == 700 ]]` bails, and `up_wait` returns 1 with no error message.

## Environment

- Omarchy: 4.0.2-1
- Kernel / OS: 7.1.9-arch1-2 (Arch Linux)
- Root filesystem: btrfs
- VM: dockurr/windows (VERSION 11), disk on `/`, bind-mounted `/storage` + `/shared` sources in `$HOME`

## Steps to reproduce

1. Configure the Windows VM so the shared-folder source dir (`$HOME/Windows`) has its setgid bit
   set, e.g.:
   ```bash
   chmod 2700 ~/Windows
   ```
   (This can occur naturally; see "Where does the setgid bit come from?" below.)
2. Run the launch (or the internal bring-up directly):
   ```bash
   omarchy windows vm launch
   # or
   pkexec /usr/bin/omarchy-windows-vm __priv up_wait
   ```
3. Observe failure without any diagnostic output:
   ```
   Starting Windows VM (this may prompt for authorization)...
   ❌ Failed to start Windows VM!
      Try checking: omarchy-windows-vm status
   ```
   while `omarchy windows vm status` reports `RUNNING`.

## What the script does

`prepare_caller_mounts()` opens both source dirs read-only, keeps them pinned via a directory FD,
then hardens them per the privacy preflight:

```bash
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || { ...; return 1; }
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
```

## Evidence

Chmod through the pinned proc-fd returns success but does **not** clear the setgid bit on the
affected directory; the subsequent stat still reports `2700` and the guard fails silently:

```
+ chmod 0700 -- /proc/16680/fd/11 /proc/16680/fd/12
++ stat -Lc %a /proc/16898/fd/12
+ shared_mode=2700
+ [[ 2700 != 700 ]]
+ exec
+ exec
+ return 1
```

Direct-path chmod behaves differently on the same directory (all as the owner and as root):

| Operation | Resulting mode |
|---|---|
| `chmod 2700 ~/Windows` (set the state) | `2700` |
| `chmod 0700 ~/Windows` (octal, plain path) | `2700` — S_ISGID not cleared |
| `chmod 0700 /proc/<pid>/fd/N` (what the script does) | `2700` — S_ISGID not cleared |
| `chmod g-s ~/Windows` (symbolic) | `700` — works |
| `chmod 700 ~/Windows` on an already-`700` dir | `700` — stable |

So only the explicit symbolic clear (`g-s`/`u-s`) drops the bit; assigning an octal mode while the
bit is present leaves it in place on this filesystem. Any fresh directory (no S_ISGID) is cleared
to `0700` normally, which is why first install succeeds and later launches fail intermittently.

## Where does the setgid bit come from?

During early boots / Windows Setup the VM node seems to (re)apply the bit to the `/shared` source
after omarchy's own chmod already passed. After an affected boot the dir is persistently `2700`,
so every subsequent launch aborts until the bit is manually removed.

## Proposed fix

Strip suid/setgid symbolically (proven to work everywhere), then assign the exact octal mode.
In `prepare_caller_mounts()`, before the existing binding logic:

```bash
# Clear stray setuid/setgid bits via the pinned handle first. An octal-only
# chmod through /proc/<pid>/fd does not drop an existing S_ISGID bit on some
# filesystems, which would otherwise leave the dir at mode 2700 and trip the
# `mode == 700` privacy guard below.
chmod u-s,g-s -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
    exec {storage_fd}<&-
    exec {shared_fd}<&-
    return 1
}
chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd" || {
    exec {storage_fd}<&-
    exec {shared_fd}<&-
    return 1
}
```

Replacing the single existing `chmod 0700 -- ...` line. The two-step form is safe: once suid/sgid
are cleared the octal assignment reliably produces exactly `0700` (verified), and the existing
post-chmod `[[ $mode == 700 ]]` guard continues to enforce the invariant.

Alternatively, `chmod u-s,g-s,0700`... — nope, keep it explicit with the two commands above.

## Verification performed

- Confirmed the failure reproduces both via `omarchy windows vm launch` and direct
  `pkexec /usr/bin/omarchy-windows-vm __priv up_wait` when `~/Windows` is `2700`.
- Confirmed `~/Windows` is the sole offender; `~/.windows` (storage source) is created `0700`.
- Cleared the bit with `chmod u-s,g-s ~/Windows` and `omarchy windows vm launch` then succeeded:
  VM started, booted, reported `Windows started successfully`, RDP connected on `127.0.0.1:3389`.
- Tested the symbolic-clear + octal-set sequence as both root and the owner; result is stable `0700`.

## Workaround for existing installs (no code change needed)

```bash
chmod u-s,g-s ~/Windows ~/.windows
omarchy windows vm launch
```

If you want it self-healing across boots, add it to a `post-boot` hook, e.g.
`~/.config/omarchy/hooks/post-boot.d/windows-vm-modes.sh`:

```bash
#!/bin/bash
chmod u-s,g-s /home/<user>/.windows /home/<user>/Windows 2>/dev/null || true
```

## Notes

- The `up_wait` failure path is otherwise silent; a diagnostic message (e.g. emit the offending
  mode) at the guard would have made root-causing this much easier. Consider hardening the guard
  to include the observed mode in the error output.
- Secondary cosmetic: `docker export`...; unrelated, excluded.