nx_lockbound_gate.nx

nx_lockbound_gate.nx -- does ss_plane_lock REFUSE a wedged plane instead of hanging on it? WHY. The 2026-08-06 commit lock closed a real defect (nx_segrace_gate: 24/24 kept vs 4/24 under a verbatim unlocked control) but it did so with a BLOCKING flock, and that changed the failure mode rather than only removing the defect. MEASURED the same day: nx_segrace_gate went RED with an UNCHANGED binary because one worker sat in kernel state D wchan=wait_for_commit -- a filesystem journal commit -- HOLDING the lock, while its siblings sat in wchan=locks_lock_inode_wait. The lock behaved correctly; the WAIT was unbounded. Trading silent data loss for an unbounded hang is not obviously a win, and it must not be discovered by whoever is on call. Debt 1786070596. ★A GUARD THAT CANNOT BE SHOWN TO FIRE HAS NOT BEEN TESTED, and a TIMEOUT is the easiest guard in the world to write and never exercise: on a healthy host the bound is simply never reached, so the code path ships untested and only runs for the first time during the incident it exists for. This gate manufactures the incident: a child DELIBERATELY HOLDS the plane lock for longer than the ceiling while the parent tries to commit through it. BOTH WAYS, because a lock that always refuses would also pass a refusal-only test: T1 CONTROL -- with NO holder, a commit must SUCCEED (the lock still works normally) T2 BOUNDED -- with a holder, the commit must be REFUSED, and refused STRICTLY BEFORE the holder lets go. Elapsed < hold time is the whole point: it proves the parent gave up on its own bound rather than simply outlasting the holder, which is the failure a naive "did it eventually return?" test cannot tell apart. license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0