cee5cffebf
This iteration set out to run the positive control the poke results need -- poke the player's hull, which the pilot logs every sample, and confirm the guest sees it. It did not run: the bind took two attempts (first fwd_cos -0.94, second 1.0) and by the time the player was being located the guest had frozen, with entities2 reporting '0 moving triples' and frozen.py confirming max_pixel_delta=0. Session tally: froze at ~70/126/150/253/610-682s and this run; ran clean at 694s (ended by the game), 936s and 1064s. Roughly two in three freeze, each costing a ~5min boot plus the window. The freeze has now truncated more experiments than every other cause combined. Restates that it is probably not ours: the mission-end freeze is recorded as pre-existing in both our build and the official AppImage, and this session produced a pilot-only freeze at 150s with no probe attached. The probe-correlation lead is real but never became a clean split. Consequence: experiments needing more than ~2 minutes of live mission should checkpoint and resume, or detect the freeze and re-run themselves. Every tool here witnesses the freeze; none survives it.