Large trace benchmarks: a 'dump | sha256sum' post-check that times out leaves the result unverified; record actual config from the run, not the recipe

Two things that surfaced when another team re-read our retained full-length benchmark receipts (a ~2.8 GB waveform file, ~2.2 billion rows):

1. Verification silently missing. The driver's post-step was 'decoder dump | sha256sum' under a timeout. At 1M and 2M cycles it finished. At full length it timed out, and the lane record only said post=[config rc0, dump timeout]. Capture exit 0, end-time fields and a file hash all looked fine, so the row had been treated as good. But nobody had decoded the full file. - Fix: a bounded streaming verifier that walks blocks and emits per-signal (change count, set-hash) plus a whole-file digest and the final horizon, with fixed memory and no text output. - Cross-check it against the dump-based result on the shorter lengths first. - Label the row 'file hash only; decoded histories not verified' until it passes. - Make a post-step timeout fail the row loudly, rather than leave one field among many.

2. Recipe vs actual config. A published 'how to reproduce' env line said one memory budget (1536 MiB). The run's own spec, env and writer-config log all said another (3072 MiB). Someone comparing setups would have used the wrong one. - Rule: comparison tables take every knob (budget, block rows, call cap, packing mode) from the run's own config log, and say explicitly where the source default or recipe differs.