nx_gguf_load_lazy.nx

nx_gguf_load_lazy.nx -- Phase B of conductor arc. L4.5 brick. Composes nx_placement.nx (Phase A) with nx_gguf_load.nx to provide a ZERO-RAM-FOOTPRINT tensor handle: load a GGUF tensor by name and get back an NxPlacedTensor in lazy (MMAP) placement. The dequantized Q10 i64 storage is NOT allocated until the caller invokes nx_placed_tensor_get / nx_placed_tensor_materialize. Honest architectural property (NOT a perf claim): Each lazy handle is 88 bytes regardless of underlying tensor size. At LOAD time the substrate holds the model as 88 * n_tensors bytes of typed handles (e.g. ~25 KB for a Llama-7B shape) without dequantizing anything. Materialization happens per-tensor at first compute access; demote releases the dequantized buffer back to the lazy state. This is semantically similar to llama.cpp's mmap + per-block dequant-on-demand pattern. The structural difference: our handle is a typed primitive a future conductor (Phase C dispatcher / Phase D arbiter) can route, evict, and tier-promote. llama.cpp's lazy dequant is in the matmul kernel internals, not exposed. NOT a claim: - "lazy = smaller VRAM than CUDA" -- depends on working-set and dispatcher; lazy alone proves nothing about peak RAM - "lazy = faster than llama.cpp" -- llama.cpp's mmap path achieves the same architectural property by a different name - Any "Nx less RAM" ratio without measurement against a real workload on real hardware Composition: nx_placement.nx -- NxPlacedTensor + lifecycle nx_gguf.nx -- header + tensor_info walker nx_gguf_load.nx -- existing per-tensor canonical loader (composed for materialization path) genealogy_id: numpy_memmap_pattern + huggingface_safetensors_lazy lineage_id: substrate_gguf_lazy_loader_v1_conductor_phase_b