### System details

- CPU: 12th Gen Intel Core i9-12900H
- GPU: Intel Iris Xe (Alder Lake-P GT2) + NVIDIA RTX 3060 Mobile
- Omarchy: 4.0.0-1
- Docker 29.7.2, Docker Compose 5.4.0, freerdp 2:3.30.0-2, dockurr/windows v5.16

### What's wrong?

`omarchy-windows-vm launch` starts the container and then exits without ever opening an RDP window. From the user's side the symptom is "only Docker comes up, no Windows window appears."

The readiness wait in `launch_windows()` greps the **entire** container log:

```bash
until docker logs omarchy-windows 2>&1 | grep -qi "windows started successfully"; do
```

`docker logs` keeps output across `docker stop` / `docker start` — it is only cleared when the container is *removed*. Any container that survives a session therefore already contains `Windows started successfully` lines from previous boots, so the loop matches on the first iteration and `xfreerdp3` is invoked roughly one second after `docker compose up -d`, while the guest is still in firmware/boot. RDP is not listening yet, freerdp fails, no window is drawn.

On this machine the guest needs ~30s from `Booting Windows using QEMU` to `Windows started successfully`, so the client is fired about 29s too early.

The same race hits a second path that has nothing to do with stale logs: when the container is already running (`CONTAINER_STATUS = running`) the readiness wait is **skipped entirely**. dockurr/windows restarts the guest inside a running container whenever Windows reboots or shuts down, so launching during that window connects to a container that is up but a guest that is not.

### Steps to reproduce

1. Launch the Windows VM and let it come up normally.
2. Close the session in a way that leaves the container in place rather than removing it — e.g. `omarchy-windows-vm launch --keep-alive`, or shut Windows down from inside the guest.
3. `docker stop omarchy-windows` (container kept, not removed).
4. `omarchy-windows-vm launch`

The container starts, the readiness loop returns instantly against the previous boot's log line, `xfreerdp3` fails, and no RDP window opens. Launching from the `.desktop` entry (`Terminal=false`) hides freerdp's error entirely, so the user sees nothing at all.

### Evidence from an affected container

```
$ docker inspect omarchy-windows --format '{{.Created}} {{.State.StartedAt}}'
2026-08-13T14:49:54Z   2026-08-14T18:07:11Z          # restarted, never removed

$ docker logs omarchy-windows 2>&1 | grep -ci "windows started successfully"
9                                                     # 9 stale matches

$ docker logs -t omarchy-windows | grep -E "Booting|started successfully" | tail -2
2026-08-14T18:07:11.878Z  Booting Windows using QEMU v10.0.8...
2026-08-14T18:07:41.886Z  Windows started successfully...   # 30s later
```

Auth and networking are fine on this host — connecting manually once the guest has finished booting works on the first try with the exact command the script builds.

### Expected behavior

`launch` waits for the guest to actually accept RDP before starting `xfreerdp3`, whether the container was just started or was already running.

### Suggested fix

Anchor the log scan to the current container start, and run the wait unconditionally instead of only on the cold-start path:

```bash
STARTED_AT=$(docker inspect --format='{{.State.StartedAt}}' omarchy-windows)
until docker logs --since "$STARTED_AT" omarchy-windows 2>&1 | grep -qi "windows started successfully"; do
```

A readiness probe against the guest would be sturdier still, since it covers guest reboots inside a long-lived container:

```bash
GUEST_IP=$(docker exec omarchy-windows awk '{print $3}' /var/lib/misc/dnsmasq.leases | head -1)
until docker exec omarchy-windows nc -z "$GUEST_IP" 3389; do sleep 2; done
```

Probing `127.0.0.1:3389` from the host does not work as a readiness check: docker-proxy accepts the TCP connection whether or not the guest is listening.

### Related

- #2599 (closed) — same user-visible symptom, fixed by adding this log-grep wait; the stale-log and already-running cases remain
- #5202 (open) — the auto-stop that follows an `xfreerdp3` failure, which makes this failure mode look like the VM refusing to start