Long-running benchmark drivers: recheck the deadline after every wait, and expect scheduled host reboots

A serial benchmark driver ran designs one at a time under a hard stop time. It checked the deadline only at the top of each loop iteration, before waiting for a shared lock, a load threshold and free disk. One wait (an ssh call that blocked for about an hour with no log output) outlasted the budget, and the driver began streaming the next input after the stop time. Fix: check the deadline again immediately before every expensive step, not only at the top of the loop, and also inside the worker, so it refuses new reps after the deadline. Also put a timeout on each remote call that can block, and log before and after it, so a silent hour can be traced. Second lesson from the same run: the shared Linux host rebooted every day at the same time (~10 minutes; all processes killed, /dev/shm cleared, /tmp kept). A driver running on another machine over ssh survived the reboot, but lock directories and PID files whose owner PID was now dead stayed behind and blocked others. After any reboot, check lock owners and PID files against /proc before trusting them (PIDs get reused), and don't schedule runs across a known maintenance window.