### System details

- CPU: Intel Core i5-6260U
- GPU: Intel Iris Graphics 540 (Skylake-U GT3)
- Omarchy: 4.0.1-1, kernel 7.1.9-arch1-2
- Docker 29.7.2, Docker Compose 5.5.0, freerdp 2:3.30.0-2, dockurr/windows 6.05

### What's wrong?

`omarchy-windows-vm launch` fires `xfreerdp3` before the guest's RDP service is
listening. The client exits after ~3s, `launch_windows()` falls through to
`priv down`, and the VM is torn down. From the desktop entry the user sees: a
polkit prompt, "Starting Windows VM…", a second polkit prompt to authorize
`__priv down`, and then nothing — no RDP window, VM stopped.

This is **not** the stale-log-lines race from #6882 (fixed, and the fix works —
see below). It is the remaining semantic gap: the log line that `up_wait` waits
on does not mean RDP is available.

`__priv_up_wait()` treats dockurr/windows' `Windows started successfully` as the
readiness signal:

```bash
if [[ -n $started_at ]] && docker logs --since "$started_at" "$CONTAINER" 2>&1 | grep -qi "windows started successfully"; then
  return 0
fi
```

That message is emitted by the image when **QEMU has booted the guest**, not when
the guest's RDP service accepts connections. Windows still has to finish booting
afterwards.

### Measurements on this machine

Container created fresh each time (`launch` ends in `down`, which removes it), so
the container log is empty at start and the `--since "$started_at"` anchor from
#6882 is working correctly — stale lines are definitively not a factor here.

| Event | Time after container start |
| --- | --- |
| `Windows started successfully` appears (→ `up_wait` returns) | **T+10s** |
| Guest actually accepts an RDP session | **T+19s** |

A ~9 second window in which `launch` connects and cannot succeed.

Measured by polling for the log line, then attempting `xfreerdp3 … +auth-only`
every 5s and recording the first attempt that reaches `NLA_STATE_AUTH_INFO`.

### Steps to reproduce

1. Have a Windows VM whose guest takes longer than the image's boot message to
   reach RDP (~19s here; slower disks/guests will be worse).
2. Ensure no container exists: `docker compose -f /var/lib/omarchy/windows/docker-compose.yml down`
3. Launch "Windows" from the app menu (or `omarchy-windows-vm launch`).
4. Authorize the first polkit prompt.

Observed: `xfreerdp3` starts with entirely correct arguments and exits after ~3s;
a second polkit prompt appears for `__priv down`; the VM is stopped; no window.

Expected: the client connects once the guest is actually reachable.

Connecting to the *same* VM once it is warm works indefinitely with the exact
same command line, which isolates this to timing rather than configuration.

### Why it is easy to miss

- It is timing-dependent: a guest that boots inside the window works fine, so it
  presents as intermittent.
- Every `launch` ends in `down`, so every start is a cold start rolling the same
  dice.
- #5202 amplifies it: because an `xfreerdp3` failure is treated as "user is done",
  the failed connection also destroys the VM, so the next attempt is cold again.

### Suggested fix

Treat the image's boot message as a precondition, not as readiness, and gate the
client on the guest actually being reachable — e.g. after the log line, poll the
guest RDP port until an RDP-level handshake succeeds (with a timeout) before
invoking `xfreerdp3`; or retry `xfreerdp3` when it fails within a few seconds of
starting, rather than falling straight through to `priv down`.

Fixing #5202 alongside this would also stop a too-early connection from taking the
VM down with it.

### Related

- #6882 — same symptom, different cause (stale log lines); its `--since` fix is
  present and working here.
- #2599 — same user-visible symptom reported on 3.10.
- #5202 — RDP client failure silently stops the VM, which compounds this.