nx_hmac_alloc_ab.nx

nx_hmac_alloc_ab.nx -- WITHIN-SUBJECT A/B: does hoisting HMAC's scratch change anything MEASURABLE? ⚠THIS EXISTS BECAUSE MY PREVIOUS ATTEMPT WAS INVALID. I compared `nx_pbkdf2_sha1` (fixed) against `pbkdf2_sha1` (untouched) -- but those bind DIFFERENT HASH CORES (nx_sha1.nx vs sha1.nx), so the comparison changed TWO variables and its 52.7s-vs-3.6s gap is uninterpretable. ★★★★★A CONTROL THAT CHANGES THE MODULE UNDER TEST IS NOT A CONTROL. I applied this correctly to the HKDF triangulation hours earlier (the SHA-256 arm held fixed as an arm that MUST NOT MOVE) and then broke it. DESIGN: ONE process, ONE hash core (nx_sha1.nx), ONE input, TWO loops of identical count: A: hmac_sha1(...) -- allocates 4 buffers per call (original) B: hmac_sha1_into(...) -- allocates ZERO per call (the fix) Everything else is held constant, so any difference is attributable to the single changed variable. ★A WITHIN-SUBJECT DESIGN REMOVES THE CONFOUND THAT A BETWEEN-BINARY DESIGN INVITES. ⚠AND IT REPORTS RSS *DELTAS PER PHASE*, NOT maxresident. maxresident was shown to be useless here: it read 4,800,000k for BOTH 100k and 200k iterations, with pagefault counts differing by ONE -- i.e. it was reporting a FIXED RUNTIME ARENA, not consumption. ★★★★★A NUMBER IDENTICAL ACROSS TWO DIFFERENT WORKLOADS IS MEASURING THE HARNESS, NOT THE WORKLOAD. If the statm reader fails, this probe says UNMEASURED rather than printing a flattering 0. license_tier: ORIGINAL expect_exit: 0