## What happened

`omarchy-windows-vm launch` frequently fails to connect on a cold boot (VM fully stopped, e.g. after `omarchy-windows-vm stop`, a host reboot, or right after a Windows Update forces a guest restart). `xfreerdp3` is invoked immediately, then fails:

```
[ERROR][com.freerdp.core.transport] - [transport_read_layer]: BIO_read returned a system error 104: Connection reset by peer
[ERROR][com.freerdp.core] - [transport_read_layer]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[ERROR][com.freerdp.core] - [freerdp_connect]: freerdp_post_connect failed
```

Without `--keep-alive`, the VM is then immediately stopped again (`launch_windows` treats the closed RDP process as "session closed" and tears the container down), so a failed cold boot silently throws away the boot progress and starts over on the next attempt.

## Why (root cause)

`__priv_up_wait()` in `omarchy-windows-vm` gates the RDP connection attempt on this check:

```bash
docker logs --since "$started_at" "$CONTAINER" 2>&1 | grep -qi "windows started successfully"
```

But the dockurr/windows entrypoint prints `Windows started successfully, visit http://127.0.0.1:8006/ to view the screen...` immediately after QEMU's UEFI hands off to `bootmgfw.efi` — i.e. right after the BIOS/UEFI stage, long before Windows itself has finished booting to a usable desktop (confirmed by watching `http://127.0.0.1:8006` at the moment `xfreerdp3` fails: Windows is still mid-boot, not at the login/desktop screen). The message name is misleading — it means "the VM process launched", not "Windows is ready".

This race gets worse right after a Windows Update, since the guest needs noticeably longer to finish booting (applying updates), making the false-positive readiness signal even more likely to fire well before RDP is actually usable.

## Expected

`launch` should only attempt the RDP connection once RDP is actually able to complete a handshake — e.g. by polling `127.0.0.1:3389` for a successful TCP connection (or a successful FreeRDP negotiation) instead of/in addition to the log-line heuristic.

## Steps to reproduce

1. Set up the Windows VM (`omarchy-windows-vm install`).
2. Fully stop it: `omarchy-windows-vm stop` (or reboot the host, or trigger a Windows Update that forces a guest restart).
3. Run `omarchy-windows-vm launch`.
4. Observe the RDP connection failing with `ERRCONNECT_CONNECT_TRANSPORT_FAILED`, immediately followed by the VM being stopped again since the RDP process exited.

## Workaround

```
omarchy-windows-vm launch -k   # keep-alive so a failed first RDP attempt doesn't tear the VM down
# wait / poll 127.0.0.1:3389 until it accepts a connection
omarchy-windows-vm launch -k   # now connects successfully
```

## System details

- Omarchy version: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- CPU: Intel Core i9-10980XE
- GPU: NVIDIA GeForce RTX 3070
- Docker: 29.7.2, Docker Compose 5.5.0
- dockurr/windows image, Windows 11 guest