GUI goldens settle on the window's idle, not two captures that agree

test/gui_golden.py hashed a scene once two captures 400 ms apart agreed;
on a loaded machine a slow frame agreed with itself before the scene's
change landed and every later hash moved up a scene. A test window now
writes a status file into its capture directory each loop step (gui.zig
writeTestStatus: step, frames captured, idle — nothing owes a frame,
nothing moves, nothing waits on the core's clock), and the harness waits
for an idle step two past the one current when it asks: a 9P write has
been served by then, so the frame is the scene's. Two things kept a
window from ever going idle, both fixed:

- Look-hover re-armed forever: resting on a word with nothing to open, the
  hover wait ran its two frames, found nothing, cancelled, and the next
  present's pointer refresh started it again: a frame every other frame
  for as long as the pointer rested there, live too (CPU). The place last
  refused is remembered (Pardes.look_hover_refused) until the pointer
  moves off it.
- The virtual clock moved only on a wait that timed out, so a steady
  trickle of events held it still; it now moves to the core's wake too
  when an event cut the wait short and nothing owes a frame.

Captures go to a directory of their own, outside the session's (a file
written there every frame is a change in the directory its panes look
at). All 17 goldens match the file as recorded at oooopqyv; eight runs,
five alongside a ReleaseFast build and three with all 16 cores saturated
(load 13-19), were byte-identical, 14 s a run unloaded (was ~30).

Tests: the resting pointer lets the core go idle.

0 files changed, 0 insertions, 0 deletions