re: third submenu sweep void -- the self-test caught a fault I introduced myself

The rework was sound and controlled. The run died because I edited and
deliberately broke the sweep script while its own run was in flight, and the sweep
read the script at its start, which fell in that window.

The self-test refused to run: constructed PERSISTS came back RESETS. Without it the
sweep would have reported RESETS for all three screens -- confident, uniform and
fabricated. First save, on the day it was written.

Three further self-inflicted faults recorded: a competing x11grab during a
measurement (the concurrency confound the port warned of), a pkill -f that can kill
the running sweep's own capture, and a restore that sat as the last line of a
timed-out command so it never ran. The process fix is to commit the tool before
running it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/submenu-sweep-3-void.txt

@@ -0,0 +1,46 @@
+# Third attempt at the three submenus' focus persistence. ❔ STILL UNMEASURED.
+# 2026-08-31. VOID, and this time the cause was ME, not the instrument.
+#
+# The tool was reworked to fix both earlier failures -- decision on the region
+# that CHANGED when the cursor moved (no per-screen geometry), and a NARROW
+# back-on-the-menu test by ring row (the thing that kept reading correctly under
+# a crash dialog). The rework was controlled on the EXTRAS frames whose answer is
+# known, and passed.
+#
+# 🔴 WHAT WENT WRONG. While the run was in flight I edited the sweep script, and
+# deliberately broke its decision rule with `sed` to test whether the new
+# self-test could fail. The sweep reads the script when IT starts -- after the
+# reach probe finishes -- and it started during that window. It read the broken
+# rule.
+#
+# ✅ THE SELF-TEST CAUGHT IT AND REFUSED TO RUN:
+#     ✅ known RESETS (real EXTRAS triple)    -> RESETS    (want RESETS)
+#     🔴 constructed PERSISTS                 -> RESETS    (want PERSISTS)
+#     ✅ constructed RESETS                   -> RESETS    (want RESETS)
+#     🔴 SELF-TEST FAILED — the rule cannot produce both verdicts.
+#
+# That is the self-test's first save, on the day it was written, against a fault
+# I introduced. Without it the sweep would have reported "RESETS" for all three
+# screens -- a confident, uniform, entirely fabricated answer.
+#
+# ⚠️ THREE FURTHER SELF-INFLICTED FAULTS, recorded because they are process, not
+# analysis, and process is what failed here:
+#
+#   1. I ran a competing test that opened x11grab captures on the same display
+#      DURING a measurement run -- the exact concurrency confound sylpheed-port
+#      had warned cost them a 7-percentage-point swing. Even had the sweep
+#      completed, its timings would carry that.
+#   2. I then cleared the strays with `pkill -f x11grab`, which can kill the
+#      running sweep's own capture. METHOD.md already records `pkill -f` matching
+#      the caller's shell; this is the same pattern biting a different way.
+#   3. My restore of the broken file sat as the LAST line of a command that timed
+#      out, so it never ran, and the broken rule stayed on disk. Recovering with
+#      `git checkout` then discarded the whole uncommitted rework.
+#
+# 📌 THE PROCESS FIX, applied: the tool is COMMITTED BEFORE IT IS RUN. An
+# uncommitted tool is one timed-out command away from being unrecoverable, and a
+# tool edited during its own run is not the tool that ran.
+#
+# ❔ The reach probe also timed out ("TIMEOUT in phase remenu"), so the menu was
+# never reached in this boot either. Whether that is ordinary boot variance or my
+# added load, I cannot separate -- which is itself the cost of point 1.