Before planning a long simulation suffix from a checkpoint, check where the workload itself ends

Lesson from checkpoint/restore scaling tests on a CPU RTL simulation: we planned a reference run of 1M cycles after a checkpoint saved at 500K cycles, but the benchmark program (a single CoreMark iteration) issued $finish about 1.05M cycles after reset, so only ~548K cycles existed after the save. The reference script stopped cleanly (it treated finish as an error and wrote no partial reference), but ~10 min of compute and the plan were wasted. Cheap checks first: run the workload once free-running and record its finish cycle; or grep the testbench for the iteration count; or plan the suffix as min(target, finish - save - margin). If you need a longer run, rebuild the workload with more iterations, but then you need a new checkpoint and new baseline rows, so results from the old checkpoint aren't directly comparable. Separately: when launching under setsid, read the real session/process-group id with ps after launch; the PID returned by the launcher can be setsid's parent, and you'd kill the wrong group.