Parallel initial sync: commitment failure causes retry on dirty state

[mh0lt]

Problem

During parallel initial sync (frozen blocks), when execution succeeds but commitment produces a wrong trie root:

1. First batch processes correctly (e.g., blocks 24363950-24368662), commits state
2. Second batch processes correctly (blocks 24368663-24368999), Flushes to sd.mem
3. Commitment at batch end fails (wrong trie root — known timing issue)
4. Stage loop tries to unwind but CanUnwindToBlockNum finds no unwindable block from changesets
5. Falls back to LatestBlockNumWithCommitment (block 24368662)
6. Retry starts from block 24368663 on TOP of the first execution's state in sd.mem
7. System call at block 24368669 reads double-applied withdrawal contract state
8. Wrong requests root hash — different error than the original commitment failure

The retry keeps producing the same requests root error indefinitely via the Caplin forkchoice loop.

Root Causes

1. No unwindable block found: The CanUnwindToBlockNum fallback silently returns the commitment block number instead of signaling that unwind is impossible.
2. sd.mem not properly reset between retries
3. Caplin retries indefinitely — the requests root error is not caught as ErrInvalidBlock

Proposed Fix

1. Make no unwindable block found fatal during initial sync
2. Fix commitment timing (commitment calculator pipeline)
3. Or: skip commitment during initial sync and compute in a separate pass

Related

• PR stagedsync: add BAD_BLOCK_HALT env var, fix parallel STOP_AFTER_BLOCK #19803: BAD_BLOCK_HALT env var
• Branch: exec3/remove-rwtx-threading

[VBulikov]

yperbasis added Imp1 as Importance