The capture-model repro flags (`--cursor-capture` / `--cursor-nochannel`) drive
relative pointer motion in circles for the whole dump, which is right for
keeping a damage-driven desktop publishing frames but makes the pointer
impossible to aim: at radius 10 every 25 ms it walks several hundred pixels a
second, so a `SetCursorPos` on the host is undone before the next frame.
That mattered because the shape UNDER the pointer is the whole question. The
arrow is a colour cursor and proves nothing about the monochrome path — the
I-beam is the only common Windows system cursor with `hbmColor == null`, so it
is the only one that exercises `mono_planes_to_rgba`. Without being able to
park the pointer on a text field there is no way to photograph the case that
matters.
`--cursor-hold` primes the wiggle for ~3 s (enough to clear CURSOR_SUPPRESSED
and get metadata flowing) and then stops, leaving the pointer wherever the host
puts it for the rest of the dump.
Used it to settle the question on .173: a `--cursor-nochannel` session — the
byte-identical wire behaviour of an iPad/Android/tvOS client, which never
advertises CLIENT_CAP_CURSOR — receives a correctly rendered monochrome I-beam
in the video. Decoded from the dump with ffmpeg; the host log shows the session
took the forced-composite path with the GDI poller live.
Verified: `scripts/xcheck.sh windows` green; `cargo fmt --all` clean.
enricobuehler
62624c1daf