nx_regprof_test.nx

nx_regprof_test.nx -- DECOMPOSE the reg_put cost. A profiler, not a gate. WHY: debt 1785519597 records "reg_put costs ~678ms per append vs reg_get ~70us". That number is REAL (measured on this host) but it is an AGGREGATE, and an aggregate names no fix. Whoever owns seg_store needs to know WHERE the 678ms goes, and the source offers two very different candidate explanations: (a) THE PLANE LOCK, added 2026-07-31. reg_put now takes <prefix>plock via sts_lock. If another writer family holds it, every put pays contention -- and the fix is scheduling, not storage. (b) THE FULL-INDEX-PER-SEGMENT SHAPE. Per the source: "every reg segment carries the FULL index", so ss_get walks every segment and each put copies the whole index forward. The fix there is the store layout, and it gets worse with every row. Those imply OPPOSITE work. u2605AN AGGREGATE THAT CANNOT DISTINGUISH TWO OPPOSITE FIXES IS NOT YET A MEASUREMENT -- it is a symptom. This probe separates them by timing the phases independently against a FRESH prefix (so segment count starts at zero) and reporting per-op microseconds for each. It also measures GROWTH: the same put timed at row 1 and at row 20. If cost is flat, the lock or a per-commit fsync dominates and (a) is the story. If cost climbs with row count, the full-index copy dominates and (b) is the story. u2605THE SLOPE, NOT THE MAGNITUDE, IS THE DISCRIMINATOR. Reports only. Kills nothing, changes nothing, writes only to its own nonce-scoped prefix. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0