nx_tool_run_timeout_gate.nx

nx_tool_run_timeout_gate.nx -- proves tr_run_capture_to actually BOUNDS a hanging child (seq1412). The claim under test is not "the function returns a timeout constant" -- that is trivial to fake. It is "a child that would run for 10 seconds is KILLED at the deadline, its output is still captured, it is REAPED rather than orphaned, and a fast child is NOT falsely timed out". So every tooth measures something an empty implementation would fail: T1 the deadline FIRES -- 10s sleeper, 500ms budget -> TR_ERR_TIMEOUT T2 the deadline is REAL TIME -- that call returns in well under the sleeper's 10s (the load-bearing tooth: returning -5 after waiting the full 10s would be a lie) T3 NEG-CONTROL fast child -- a 50ms sleeper with a 5s budget exits 0, NOT timed out T4 output survives -- the fast child's stdout is captured intact T5 REPEATABLE -- a second timeout run behaves identically; resource-leak accounting requires separate lifecycle evidence T6 opt-out is explicit -- timeout_ms<=0 delegates to the unbounded path and still succeeds license_tier: ORIGINAL No hw writes (Rule 26). expect_exit: 0