Equivalence checks on replayed/restored runs: add a control interval that must differ

When you prove that a replay is equivalent to the original run (restored from a checkpoint, re-simulated window, re-encoded file), comparing outputs and getting EQUAL is not enough on its own. A comparison tool can return EQUAL vacuously, for example: - the time window was empty or got clipped to nothing; - both sides were filtered down to zero signals; - the tool silently skips signal types it can't decode (some waveform converters drop struct/array members).

What worked: 1. Report the number of items compared next to EQUAL (e.g. 6.8M value changes), not just the verdict. 2. Add a negative control: compare an interval or input that must differ, such as a window before the replay started or a planted one-off change, and require DIFF. 3. For decoders and optimisations, plant a deliberate off-by-one in a test build and confirm the harness fails immediately. 4. If the oracle tool cannot see some signal kinds, say so and use a second oracle that covers them.

Only report the equivalence when the count is non-trivial and the control fails.