TemporalMemBatch.Unwind stored the incoming changeset in sd.unwindChangeset,
a map keyed by change.Key[:len(change.Key)-8] — i.e. the real key with the
step suffix stripped. That's the shape getLatest needs for its fallback
lookup (one pre-unwind value per real key), but Flush was re-exporting the
same collapsed map to tx.Unwind and into DomainRoTx.unwind — so only one
entry per real key survived, no matter how many (key, step) pairs the
original diff carried.

Each entry drives a DupSort DeleteCurrent at a specific step. When a key
was touched inside more than one step of the unwound range (e.g. a
commitment branch written to step N and N+1 during forward execution),
only one step's dup got deleted and the rest remained as orphans. For the
commitment domain this left the "state" key pointing at a blockNum beyond
the unwind target, and on the next open SeekCommitment returned that
stale block — so execution started past TxNums.Last() and rejected the
next block with "nonce too high" (observed on mainnet after three
forkchoice-driven ~54-block unwinds: 22k orphan step-8860 entries plus a
state key frozen at blockNum=24923992).

Fix: keep a separate unwindChangesetRaw alongside the collapsed map.
Flush replays the raw (step-preserving) list against tx.Unwind;
getLatest still consults the collapsed map. Merge and ClearRam carry and
clear the raw copy too.

New tests cover single-unwind across a step boundary and three
successive unwind cycles; both now verify the commitment "state" blockNum
and the values-table step tags.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Both post-unwind commitment-state checks were wrapped in `if len(stateVal)
>= 16 { ... }`. If a future bug ever deleted or truncated the state key,
the test would silently pass — exactly the failure mode these tests try
to catch. Switch to `require.GreaterOrEqual(len, 16)` so the assertion
fails loudly instead of being skipped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ent-unwind-divergence

Addresses PR feedback that the raw-changeset Flush fix was only covered
for live-value writes; deletes use the same DomainUpdate path but emit
a tombstone dup (^step || nil, 8 bytes) whose side effects on the
DupSort sort order are easy to reason about incorrectly.

Scenario: write addr in step 0, overwrite in step 0, delete in step 1,
then unwind to a block inside step 0 via doms.Unwind() + doms.Flush().
The collapsed-map Flush would replay only the step-0 restore diff and
leave the step-1 tombstone in MDBX — and since ^1 sorts before ^0 in
DupSort, SeekExact would return the tombstone, getLatestFromDb would
interpret the 8-byte value as "absent", and the account would look
deleted instead of restored to its block-0 value.

Verified: FAILS against a reverted Flush (uses the collapsed map) with
"post-unwind: addr must be restored (got empty slice — step-1 tombstone
was not cleaned up)", PASSES against the raw-list Flush.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>