…han (#20710)

## Summary

`TemporalMemBatch.Unwind` stored the incoming changeset in
`sd.unwindChangeset`, a map keyed by `change.Key[:len(change.Key)-8]` —
the real key with the 8-byte step suffix stripped. That shape is what
the `getLatest` fallback needs (one pre-unwind value per real key), but
`Flush` was re-exporting the same collapsed map to `tx.Unwind` →
`AggregatorRoTx.Unwind` → `DomainRoTx.unwind`. Because only one entry
per real key survived the collapse, per-step `DeleteCurrent` calls fired
for only one step per key and orphan domain-values entries were left
behind at every other step.

On mainnet this manifested as the commitment domain drifting one step
ahead of every other domain after a sequence of forkchoice-driven
unwinds. `SeekCommitment` then returned a stale `blockNum` above
`TxNums.Last()`, execution started past the truly-executed tip, and the
next block was rejected with `"nonce too high"`.

Fix: keep a separate `unwindChangesetRaw` (step-preserving) alongside
the collapsed map. `Flush` replays the raw list against `tx.Unwind`;
`getLatest` continues to consult the collapsed map. `Merge` carries (and
`ClearRam` clears) both copies.

## Why

On a mainnet node, `integration print_stages` showed:
```
accounts    progress(txnum) 3460929701   step 8859
storage     progress(txnum) 3460929699   step 8859
code        progress(txnum) 3460929625   step 8859
commitment  progress(txnum) 3460937500   step 8860   <-- ahead by one full step
receipt     progress(txnum) 3460929700   step 8859
```

A direct read of the commitment values table turned up 22,038 orphan
step-8860 entries plus the `"state"` key pointing at `blockNum=24923992`
after execution had been unwound to 24923939. The observable symptom was
an endless `invalid block, txnIdx=2, nonce too high: address
0x13c12Fe9…, tx: 14 state: 13` retry loop every ~12s.

## Repro

New test `TestSharedDomain_RepeatedUnwindAcrossStepBoundary` writes
accounts+commitment across three steps, runs three (execute, flush,
unwind-to-earlier-step, flush) cycles and asserts that
- the commitment `"state"` key's decoded `blockNum ≤ unwindTarget`, and
- the commitment values table has no entries with `step >
unwindTarget/stepSize`.

On main this fails with `step=2 bn=29 / step=1 bn=19` dups still present
after every unwind; with the fix the only remaining dups are at step 0
(the unwind-target step) and the latest points at the restored block.

`TestSharedDomain_UnwindAcrossStepBoundary` is a simpler single-unwind
regression guard for the same invariant.

## Notes

- The `Merge` path now merges `unwindChangesetRaw` with the same
newer/older directionality as `unwindChangeset`. It uses
`changeset.MergeDiffSets`, which already dedupes by full `(key, step)` —
so this doesn't reintroduce the collapse bug.

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: info@weblogix.biz <admin@10gbps.weblogix.it>
(cherry picked from commit 2813e8f)