## What happened

Setting up the Windows VM (`omarchy windows vm install` / `omarchy-windows-vm`) fails in two distinct ways on this machine:

### 1. `~/Windows` (the Samba shared folder) gets `setgid` set after the container runs, permanently blocking every subsequent `omarchy windows vm launch`

After the very first successful `docker compose up` of the `dockurr/windows` container, the host directory bound to `/shared` (`~/Windows`) ends up with mode `2700` (setgid bit set) instead of `0700` — almost certainly set by the container's own Samba init.

`omarchy-windows-vm`'s `prepare_caller_mounts()` requires both `~/.windows` and `~/Windows` to be exactly mode `700` after an internal `chmod 0700 -- "/proc/$BASHPID/fd/$storage_fd" "/proc/$BASHPID/fd/$shared_fd"` call (see `assert_mounts_safe` / `prepare_caller_mounts` in `/usr/share/omarchy/bin/omarchy-windows-vm`). On this system (BTRFS home), a **numeric** `chmod 0700` on a directory that already has the setgid bit set does **not** clear it — only a symbolic `chmod g-s` does. Since the script's chmod is numeric, the check `[[ $storage_mode != 700 || $shared_mode != 700 ]]` keeps failing, and `prepare_caller_mounts` (and therefore every `omarchy windows vm launch`/`up`) fails silently (no error surfaced to the user beyond "Failed to start Windows VM!").

**Repro:**
1. `omarchy windows vm install`, let it run once successfully (or even partially, enough for the container to start).
2. `omarchy windows vm stop` (or close RDP so it auto-stops).
3. `stat -c '%a' ~/Windows` → shows `2700`.
4. `omarchy windows vm launch` → fails with no useful error (`❌ Failed to start Windows VM!`).

**Workaround:** `chmod g-s ~/Windows` before every launch attempt.

**Suggested fix:** either use `chmod g-s`/`chmod --reference` semantics instead of (or in addition to) the numeric `chmod 0700` in `prepare_caller_mounts`, or explicitly strip setgid (`chmod g-s`) as part of the safety check before comparing modes.

### 2. Windows fails to boot inside the container: `KVM: entry failed, hardware error 0x0`

Once mounts succeed and the container starts, QEMU crashes immediately on the very first `KVM_RUN`, before any BIOS/firmware output:

```
❯ Booting Windows using QEMU v11.1.0...

KVM: entry failed, hardware error 0x0
EAX=00000000 EBX=00000000 ECX=00000000 EDX=000a06a4
...
EIP=00000000 EFL=00000000 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
...
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
EFER=0000000000000000
❯ ERROR: Timeout while waiting for QEMU to boot the machine, terminating...
```

Tried and ruled out:
- Pinning the container to the host's P-cores only via `cpuset: "0-7"` (this CPU is a hybrid Meteor Lake with P-cores on cpu 0-11, E-cores on 12-21) — no change.
- `HV: "N"` (disable Hyper-V enlightenments) — no change.
- `CPU_MODEL: "qemu64"` (generic model instead of the default `host` passthrough) — no change, same crash (just a different `EDX` signature).

Since even the most minimal generic `CPU_MODEL` fails identically at the very first instruction, this doesn't look like a CPU-feature-passthrough problem — more likely a KVM/QEMU/kernel incompatibility specific to this host, or a genuine QEMU 11.1.0 (the version bundled in the `dockurr/windows` image) regression on newer Intel hybrid silicon.

## Expected

`omarchy windows vm install` / `launch` should produce a bootable Windows 11 VM.

## System details

- Omarchy version: `4.0.3-1`
- CPU: Intel Core Ultra 7 155H (Meteor Lake, hybrid P+E cores)
- GPU: Intel Arc Graphics (Meteor Lake-P, integrated) `[8086:7d55]`
- Kernel: `7.2.3-arch1-3`
- Docker server version: `29.7.2`
- `/home` filesystem: BTRFS (`@home` subvolume)
- KVM: `/dev/kvm` present, `vmx`/`ept`/`unrestricted_guest` all available and enabled per `/sys/module/kvm_intel/parameters/*`
- `dockurr/windows` image: QEMU v11.1.0 (as reported in container logs)

## Notes

Issue 1 is fully reproducible and root-caused. Issue 2 is reproducible but the root cause is unconfirmed — filing both together since they were both required to get a working install on this machine, and issue 1 must be fixed before issue 2 can even be reached on a second launch attempt.