nx_memfloor.nx

nx_memfloor.nx -- ADMISSION CONTROL FOR A LARGE ALLOCATION, as a shared library. WHY THIS EXISTS (2026-07-30 incident, second of its class): nx_skullsdf.elf held 27.7 GB of a 36 GB host inside 2m48s, drove swap to 98% and load to 41, and the mgmt API began refusing builds ("host below the memory floor"). Its grid resolution comes straight from argv with no upper bound, and the allocation is O(g^3): G=1500 -> 1501^3*8 = 27.06 GB, which is exactly what was observed. seq1547 was the same shape in nx_ssdf (28 GB in 227s), and that one took mgmt, the tools daemon and sshd down with it. THE POINT: the ecosystem ALREADY knew how to do this. nx_build_admit refuses to fork the compiler below a memory floor, and nx_headroom exposes the floor + load ceiling as a CLI. Neither was reachable from inside an organ about to allocate, so every heavy organ re-decided the question -- and the ones that never asked are the ones that ate the host. This is the adoption gap, not a missing primitive: MIGRATE THE CHOKEPOINT, NOT THE LEAF. CONTRACT: call mf_admit_bytes() with the EXACT byte count you are about to map, BEFORE you map it. Returns 1 = admit, 0 = refuse. On refuse the caller must fail fast and say so -- never allocate anyway, and never silently shrink the request (a caller that asked for a 1500-cell grid and quietly got 160 would emit a wrong answer, which is worse than an honest refusal). Lives in runtime/ so _hdl_build/ organs can import it; the reverse never resolves. license_tier: ORIGINAL