nx_constscan_beat.nx

nx_constscan_beat.nx -- STANDING guard for LM-030, the const-pointer direct-index SILENT MISCOMPILE. WHY A BEAT: on 2026-07-30 I reproduced LM-030 with a controlled probe/control pair -- CONST[i] compiles clean, runs, and returns WRONG DATA with no diagnostic anywhere -- then scanned all 17,501 .nx in the tree and found hits=0. Clean TODAY is not a property; it is a snapshot. A defect whose only symptom is a wrong number needs a continuous guard, because the first reintroduction is invisible by construction. WHY THE DETECTOR WAS DARK, which is the real lesson: nx_doc_constscan already existed and had even measured the same garbage value, but it was SOURCE-ONLY -- never built, never in tool_allowlist.conf, never on the sweep rail. A detector nobody can run is not a guard. This beat is the missing rail. Discovers + batches + aggregates ONLY. It forks the proven ./nx_doc_constscan_run.elf exactly as nx_store_fold_beat forks nx_store_compact, so the DETECTOR keeps sole ownership of what counts as a hit. Batching exists because the runner takes files as argv and the tree is ~17.5k files -- one exec cannot hold them, so this is xargs-in-an-organ, not a re-implementation. Sweep-row contract: exit 0 = zero LM-030 sites; exit 1 = at least one, surfaced RED with the count. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0