_simsize_gate.nx

_simsize_gate.nx -- STRUCT-SIZE-vs-ALLOCATION gate. NO mocks. WHY THIS EXISTS (measured 2026-08-07): FIFTEEN live sources allocated NxRv64imSim with a hardcoded `sys_mmap(128)`. 128 bytes is 16 i64 slots; the struct had grown to 26 fields = 208 bytes. So `halted` (offset 128), `halt_code` (136) and `steps` (144) -- THE THREE FIELDS EVERY BOOT VERDICT IS COMPUTED FROM -- were written and read OUT OF BOUNDS. It hid for months inside 4 KiB page slack and surfaced only when NXA_SMALL_MAX went 64 -> 256 and a 128-byte request began being served from the shared small arena, landing the overrun on a live neighbour. The symptom was nx_boot_run_sov reporting steps=1953655343 = 0x74726976 = the ASCII "virt" of the virtio magic the driver under test had just read. A HARDCODED BYTE SIZE FOR A STRUCT THAT KEEPS GROWING IS AN OUT-OF-BOUNDS WRITE ON A TIMER. The remedy is not a bigger number -- a bigger number just resets the timer. The remedy is a RULER: re-derive the field count FROM SOURCE on every run and refuse if the declared allocation constant cannot hold it. T1 REAL -- NxRv64imSim fields*8 <= NX_RV64IM_SIM_BYTES, BOTH parsed from rv64im_min_sim.nx. T2 NEG CTL -- a fixture whose struct provably does NOT fit its constant must be REFUSED. Without this tooth the gate would score its loudest PASS when it parsed nothing. T3 PARSER -- a fixture with a KNOWN field count must return EXACTLY that count. T1+T2 alone are both satisfied by a parser that always returns 0; this tooth kills that. Evidence -> knowledge/status/simsize.log (SIMSIZEGATE row). Sovereign. license_tier: ORIGINAL