nx_guarded_run.nx

nx_guarded_run.nx -- the team's HANG-HANDLING capability (operator: "make sure the team is getting built to handle issues like this hang", 2026-06-10). module: nishi-core.exec.guarded_run capability: CORE_COMPUTE + GATE WHY: nx_sov_build_run's sbr_run forks + wait4(blocking) with NO deadline, so a child that hangs in a syscall (e.g. the validated-HTTPS read loop wedging on a host like en.wikipedia.org that never cleanly EOFs) wedges the runner -- and therefore the GATE -- forever. This session proved two things the hard way: (1) such hangs are REAL (example.com fetches 868B fine; wikipedia hangs 220s+); (2) plain `timeout` (SIGTERM) does NOT reap them -- only SIGKILL does. nx_guarded_run makes ANY run hang-proof: fork the child, poll wait4(WNOHANG) against a wall-clock DEADLINE, and on breach SIGKILL it and report a distinct TIMEOUT verdict the caller files as a defect instead of hanging. Sovereign: pure sys_fork/execve/wait4/nx_kill -- no GNU `timeout`, no shell. This is the substrate the Doctor/Engineer wrap around every crawl/fetch/build gate so a network or miscompile hang becomes a deterministic, filed TIMEOUT -- never a wedged session. Pairs with nx_progress_watchdog (in-process stall detection); this is the out-of-process KILL the watchdog lacks.