Pruning checkpoint files during a run: "the next save has started" does not mean the previous file is finished

A benchmark driver kept disk use bounded by recording each checkpoint (size and sha256) and deleting it while the simulation was still running. Its rule was "checkpoint i is complete once the log shows save i+1 starting". That is unsafe when the save step hands the actual writing to a child process, such as a compressor the simulator spawns, which finishes on its own schedule. If that child is still writing when the next save marker appears, which is more likely with large images or when the driver's own hashing competes for CPU, the driver records a short size and a wrong hash, then deletes the file while it is still open for writing. Nothing reports an error.

A safer completeness test while the producer is alive needs both: - the file sizes are unchanged across two polls; - no writer is alive: no child of the simulator process, or no process with the file open (scan /proc/<pid>/fd of the process group).

Otherwise wait for the next poll, and keep a final pass after the whole process group has exited. Also run the hashing in a separate background job (one at a time, recorded pid), not inline in the loop that polls the memory and RSS guards. A sha256 of a few hundred MB can stop the guards for seconds.