nx_pbkdf2_leak_probe_old.nx

CONTROL ARM. Identical probe, but bound to the UNMODIFIED family: pbkdf2_sha1.nx -> hmac_sha1.nx -> sha1.nx, none of which received the scratch fix. ★★★★★A BEFORE/AFTER COMPARISON AT DIFFERENT PARAMETERS IS NOT A COMPARISON -- my 'pre-fix 16 KB/iteration' was EXTRAPOLATED from a partial run, and the extrapolation was doing all the work. This measures the unfixed path directly so the two rates are comparable per-iteration. c is halved to 100,000 to keep the unfixed path from exhausting the VM again. nx_pbkdf2_leak_probe_old.nx -- BOUNDED VERIFICATION THAT THE PBKDF2 mmap LEAK IS ACTUALLY FIXED. WHY A PROBE AND NOT THE FULL RFC 6070 VECTOR: vector 4 is c = 16,777,216. Before the fix that leaked ~16 KB/iteration (MEASURED: 11.3 GB resident, 3.18M pagefaults, 5.62s user vs 405.88s system, ~4% complete in 10m39s => ~260 GB and ~4h to finish). It also destabilised the WSL VM twice. Re-running it to prove a fix would take hours and risks the same collateral. So this probe runs a FIXED, SMALLER count and lets ARITHMETIC do the rest. The pre-fix rate is known and measured, so the prediction is exact and falsifiable: c = 1,000,000 -> PRE-FIX ~16 GB resident (1e6 x 16 KB) POST-FIX a few MB, FLAT, independent of c A 1000x separation cannot be explained by noise, so one run decides it. ★★★★★A FIX IS NOT VERIFIED BY THE ABSENCE OF THE OLD SYMPTOM -- IT IS VERIFIED BY A NUMBER THAT MOVED IN THE PREDICTED DIRECTION BY THE PREDICTED MAGNITUDE. "It didn't hang this time" would be worthless here; maxresident is the instrument. ⚠THIS PROBE MAKES NO CORRECTNESS CLAIM. It says nothing about whether the derived key is right -- that is nx_pbkdf2sha1_extvec_gate's job against RFC 6070 (vectors 1-3 PASS). ★A PERFORMANCE PROBE THAT ALSO CLAIMED CORRECTNESS WOULD BE TWO INSTRUMENTS IN A TRENCHCOAT. Run under: time ./elf license_tier: ORIGINAL expect_exit: 0