**omarchy-windows-vm: a single launch click can never work from a cold start — FreeRDP connects before the Windows guest finishes booting, gets "connection reset", gives up, and the launch stops the VM**

Version: omarchy 4.0.4-1 (current repo version), kernel 7.2.5-3-omarchy, dockurr/windows container.

### What happens

`omarchy-windows-vm launch` (e.g. via the desktop menu entry) with no running container:

1. `__priv_up_wait` returns as soon as the container logs contain `Windows started successfully` — but in dockurr/windows that message is printed when the QEMU display is ready, **before** the Windows guest has finished booting (a cold boot takes several minutes).
2. `launch_windows` immediately runs `xfreerdp3`. The container's RDP proxy accepts the TCP connection right away, but the guest's RDP service isn't up yet, so FreeRDP gets `BIO_read ... Connection reset by peer` / `ERRCONNECT_CONNECT_TRANSPORT_FAILED` twice within ~7 seconds and exits (`freerdp_post_connect failed`).
3. The script treats that as "RDP session closed" and stops/removes the container, throwing away the boot progress.

Net effect: the user clicks Windows, sees nothing, and every subsequent attempt repeats the same loop. A launch only succeeds if the container was left running long enough for the guest to fully boot (e.g. because the auto-stop was declined), or if something outside the script already waited.

### Evidence (from a real cold start)

```
[16:48:11] xfreerdp3 starts (container started seconds earlier)
[16:48:14] BIO_read returned a system error 104: Connection reset by peer
[16:48:18] BIO_read returned a system error 104: Connection reset by peer
           freerdp_post_connect failed
RDP session closed. Stopping Windows VM...
```

Reconnecting ~5 minutes later (container still running, guest fully booted) connects instantly and the RDP session works fine — confirming the guest just wasn't ready yet.

### Suggested fix

Before invoking `xfreerdp3` in `launch_windows`, poll until the guest's RDP service actually answers. A plain TCP connect is not sufficient (the proxy accepts immediately); probe with a real X.224 connection request, e.g.:

```bash
  # The container's RDP proxy accepts TCP before the guest finishes booting;
  # poll with an X.224 connection request until the guest answers.
  local rdp_deadline=$((SECONDS + 480))
  until timeout 6 bash -c 'exec 3<>/dev/tcp/127.0.0.1/3389 && printf "\x03\x00\x00\x13\x0e\xe0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x03\x00\x00\x00" >&3 && head -c 1 <&3' 2>/dev/null; do
    ((SECONDS < rdp_deadline)) || break
    sleep 3
  done
```

I've been running exactly this patch locally; from a full cold start the launch now waits through the guest boot and the RDP session connects on the first click. (Alternatively, FreeRDP could be wrapped in a bounded retry loop, but the readiness probe is cheaper and keeps the single-connect behavior.)

Related but distinct: the setgid/`chmod 0700` launch failure — already tracked in #11940 (closed) with open PRs #12323 / #10595 / #12019 / #12264. This issue is independent of that fix.