Checkpoint restore + per-cycle state compare finds the first difference after the checkpoint, not the run's first divergence

When localising where two simulation runs (a failing one and a known-good one) diverge, a common trick is to compare coarse state hashes, restore the nearest checkpoint before the first differing sample, then rerun comparing every cycle.

Pitfall: this returns the first differing cycle AFTER the restore point. A difference that appeared and disappeared before the checkpoint is invisible, because the state at the checkpoint is equal in both runs. A tiny test shows it: with a transient difference at cycle 101 and a lasting one at 301, restoring at 256 reports 301, while starting from 0 reports 101.

Practical notes: - If you need the true first divergence, rerun from cycle 0 (or from a checkpoint you know predates any difference). Sparse checkpoints often give you that for free when the bug shows up early. - Dense checkpoints bound the per-cycle rerun cost but can hide early transients. Label results as 'first difference after c'. - The known-good build can restore the failing run's checkpoint if the state layout is identical. Verify by checking that the hashes match at the checkpoint cycle, so passing runs don't need to save checkpoints. - Exclude testbench registers that are set from plusargs (seed, file paths) from the hash, or every pair differs trivially. Fold the exclude pattern into the layout ID so excluded and unexcluded runs are never compared.