The doc carried a 🟡 saying cross-run stability was untested. Tested now on a fresh guarded Stage 02 run (stage asserted): the HUD reads "Remaining OB : 004" while RAM at the documented 0xbdb59668 reads 95748078, constant over four samples 12s apart. Not 4, not near 4, not moving. So the address belongs to that run's heap, as the corpus's own heap-reallocation warning predicts. No constant-shift shortcut either: a BE u32 equal to 4 occurs 1654 times within +-1 MB of the old address and 11202 times within +-16 MB, far too many to isolate without the transition filter. The durable result is the METHOD (ob_scan.py: scan at one value, filter against live memory at a DIFFERENT value), not the number. Also fixes a contradiction in INDEX.md, which said in one row that the address is "still ❔" while another row linked the doc that had already CONFIRMED it.
566 KiB
1279x675px
566 KiB
1279x675px