nx_hash_index_bench.nx

nx_hash_index_bench.nx -- IN-NISHI read-path exceed: sovereign O(1) hash index vs binary search. Honest finding: the seg_store binary-search get (~502 ns/op, ~15 variable-length key compares) is SLOWER than sqlite's cached B-tree probe (~250 ns, measured once as the cited 3rd-party baseline). The read path was a DEFICIT, not an exceed. The Nishi-ecosystem fix (no shells): an O(1) sovereign hash index -- FNV-1a over the key -> open-addressing linear-probe table -> 1 hash + ~1 compare per get. This organ builds both a sorted index (binary search) and the hash index over the SAME 20000 keys and times 20000 gets each, in one run, fully in-Nishi. sqlite ~250 ns/get = CITED by-design reference (the doctrine: prove vs 3rd-party in the harness; here cited, not shell-run). KAT: both indexes correct (all 20000 gets hit); the hash get is FASTER than binary search (the in-Nishi win); reports hash ns/op vs sqlite's cited 250 ns (the read exceed, if hit). No hw writes (Rule 26). expect_exit: 0 license_tier: ORIGINAL