e3098f7316
Ran this file's own transition filter on a guarded Stage 02 run (stage asserted), reading the HUD from a crop taken at the same instant as each memory sample: scan at HUD 004 -> 41537 candidates; filter at HUD 008 -> 8; verify across the 008 -> 012 transition, which was NOT selected on -> exactly ONE survivor. That survivor, 0xbdb69668, tracked 4 -> 8 -> 12 against the HUD's 004 -> 008 -> 012. The other seven collapsed into noise at the first unselected transition, which is precisely what that rule exists to catch. The file's "try 0xbdb59668 first, re-scan when it reads 0" rule worked verbatim: it read a hard 0 here, and the re-scan cost about the predicted five minutes. The ...9668 page-offset pattern is REFINED, not reinstated: the three located addresses (0xbdb49668, 0xbdb59668, 0xbdb69668) are three ADJACENT 64 KB pages at one offset, and in this run exactly one of 8192 probed pages held 12 -- the counter -- making it a one-step lookup. But the 2026-08-26 refutation stands as measured (zero ...9668 VAs held the HUD value in that run), so this is a fast heuristic to be HUD-checked, not a law.