_gpu_dxg_submit_gate.nx

_gpu_dxg_submit_gate.nx -- SOVEREIGN-GPU ladder R5 (a REAL command submission ACCEPTED by the 5080). R4f pinned allocations resident. This rung drives LX_DXSUBMITCOMMAND itself: a well-formed submission carrying a mapped, resident pushbuffer GPU-VA and a resolved context, accepted by dxgkrnl on the real discrete RTX 5080 -- wrapper-free, no libcuda / libvulkan / libd3d12 / libdxcore / libc. THE ABI WAS MEASURED, NOT GUESSED. Two recon sweeps established it against the live device: * ioctl SIZE: sweeping the size field with broadcast_context_count=0 (which cannot start GPU work, so it cannot TDR), exactly ONE size answers -EINVAL (recognised, contents rejected) while every other size answers -ENOTTY (unknown ioctl). That size is 384 => SUBMIT_CODE 0xC180470F. * FIELD OFFSETS: with command_length=0 (a no-op submit: well-formed, the GPU executes 0 bytes), only the layout whose count and context fields are both correct lets the context RESOLVE and returns 0; every wrong layout leaves the count zero or the context unresolved and returns -EINVAL. Exactly one of five candidate layouts answered 0: broadcast_context_count@0x18, broadcast_context[0]@0x1c. GREEN iff (author=organ, every value from a REAL device return): A) the full chain resolves: enum -> discrete adapter -> device -> context -> paging queue -> EXISTINGHEAP allocation -> GPU VA -> resident; B) SUBMIT ret == 0 (dxgkrnl ACCEPTED the submission); C) the accept is REPEATABLE -- the mechanism, not a one-shot; D) TAMPER matrix, each from a DIFFERENT real rule, every one differing from the real ret==0: T1 count at the WRONG offset (0x14) -> context never resolves; T2 bogus context handle -> real validation rejects; T3 correct struct but the WRONG ioctl size (392) -> -ENOTTY from the size-encoded command number; T4 the same well-formed submit on a NON-dxg fd (/dev/null) -> -ENOTTY. T3 and T4 together are what stop "any ioctl returns 0" from passing as an accept. E) a POSITIVE CONTROL after the tampers: the channel still accepts, so this is not a guard that refuses everything once poked. SCOPE -- READ THIS BEFORE QUOTING THE GREEN. command_length is 0, so THE GPU EXECUTES ZERO BYTES. This rung proves the SUBMISSION CHANNEL accepts a well-formed command with a resolved context and a resident pushbuffer. It proves NO throughput, NO kernel execution, and NO speedup, because a zero-length buffer contains no instructions. Running actual work needs NVIDIA Blackwell ISA (SASS) encoded into that pushbuffer -- that is the next rung and it is NOT claimed here. A green here that was read as "we run compute on the 5080" would be exactly the false-green this gate is shaped to prevent. ⚠RUN IT ON THE HOST THAT HOLDS THE GPU. The build root has no /dev/dxg; the gate reports UNOBSERVABLE and exits CLEAN there, so a RED from this gate always means the GPU path actually broke. license_tier: ORIGINAL expect_exit: 0