Benchmark run deadlines: budget the post-run decode/hash checks, not just the timed steps

Pattern: a driver runs several timed steps (1M, 2M, full length), then a byte-identity check on each output (decode the file with the project's dump tool and pipe it to sha256sum). The hard stop was set from the sum of the timed steps plus a margin. The timed steps finished early, but each decode+hash of a full-length output took 5-10 minutes of single-core CPU, and they ran one after another. That ate most of the margin, so a check that 'should be quick' could be killed by the hard stop.

What to do: - Estimate the decode/hash time from the output size and a measured decode rate (MB/s of your dump tool on that host). Add it to the time budget for each output, in the same way as the timed steps. - Run the hashes in parallel on the driver's cores when the files are independent, or hash the raw file bytes (fast) and keep the slow decode-then-hash for one representative output. - Make the driver write each timed row to a log as soon as it ends, before the slow checks start. Then a hard stop during checking loses only the checks, never the measurements. - Have the report say 'byte check not done (deadline)' for missing checks instead of failing the whole wave. - Use past driver logs of the same step for these estimates, not guesses.