The parallel commitment calculator (when forcePerBlockCompute is on)
calls SharedDomains.GetChangesetByBlockNum from its own goroutine
while the exec loop calls SavePastChangesetAccumulator. Both touched
TemporalMemBatch.pastChangesAccumulator without any locking, racing
on map iteration vs map write — surfaces as
"fatal error: concurrent map iteration and map write" on the
TestLowDiffLongChain reproducer.

Add a sync.RWMutex (pastChangesLock) and protect:
  - SavePastChangesetAccumulator (write)
  - GetChangesetByBlockNum (read)
  - GetDiffset's lookup of the cached changeset (read)
  - Merge's iteration over another batch's pastChangesAccumulator
    (write on self, read on other)

flushDiffSet remains unlocked: it runs at the end of the stage after
the calculator goroutine has already stopped (defer Stop in pe.exec
runs before stageloop's commit), so no race window remains there.

…r parallel calculator

pastChangesAccumulator can hold multiple changesets per block number after
a fork-bounce reorg (canonical block N + forks[i] block N saved with
different hashes). The existing GetChangesetByBlockNum iterates the map
and returns the first match — non-deterministic in Go's map iteration
order.

The parallel commitment calculator's per-block compute wrap (and
FlushPendingUpdates) used number-only lookup, occasionally routing a
block's [state] / branch writes to the wrong block's CS during reorg-
heavy tests like TestBlockchainHeaderchainReorgConsistency.

Fix:

- Add BlockHash to PendingCommitmentUpdate so the deferred-flush path
  carries the hash through to FlushPendingUpdates.
- Add SharedDomains.GetChangesetByHash + TemporalMemBatch.GetChangesetByHash
  for exact (BlockNum, BlockHash) lookup.
- Calculator's computeWithBlockAccumulator now uses hash-aware lookup
  and stamps PendingUpdate.BlockHash after compute, so the next call's
  FlushPendingUpdates routes deterministically.
- Applied the wrap to all three compute paths (computeAndCheck,
  computeAndPublish, computeWithoutCheck) so first-block-isPartial
  paths don't bypass it.
- FlushPendingUpdates prefers GetChangesetByHash when upd.BlockHash is
  set, falls back to legacy lookup otherwise (preserves behavior for
  callers that don't yet thread the hash).

Note: this fix eliminates a real source of non-determinism but does
NOT fully fix TestBlockchainHeaderchainReorgConsistency on its own —
that test exhibits a deeper issue where iter 1's re-execution of the
canonical chain produces empty cc.updates and the calculator's
ComputeCommitment skips the [state] write entirely. Investigating in
follow-up work.

…writeset normalization

Closes the off-by-one wrong-trie-root cluster and TestRecreateAndRewind
under EXEC3_PARALLEL=true. Two coupled fixes:

(1) Concurrency band-aid on SharedDomains.changesetMu

The parallel commitment calculator briefly swaps the global
"current changeset accumulator" pointer to route block N's branch
writes into block N's saved CS (computeWithBlockAccumulator). During
that swap window, the apply goroutine concurrently calls DomainPut for
block N+1's account/storage writes — those land in block N's CS instead
of block N+1's. On a later unwind, block N+1's CS lacks the prev-value
for those writes, the executor reads stale state, and reorg/fork tests
fail with wrong trie roots (TestBlockchainHeaderchainReorgConsistency,
TestLongerForkHeaders, TestLongerForkBlocks, TestCallTraceUnwind).

Add changesetMu on SharedDomains. Calc holds Lock around its swap+
compute+restore via LockChangesetAccumulator/UnlockChangesetAccumulator;
apply-side DomainPut/DomainDel take Lock briefly per non-Commitment
write. CommitmentDomain writes (only the calc writes those) are
exempted to avoid self-deadlock with the calc's outer Lock.

Public Set/GetChangesetAccumulator now lock internally (used by serial
exec, exec3_parallel, tests). The new *Locked variants are for callers
that already hold the mutex (the calc).

(2) SD-aware writeset normalization + calc SelfDestructPath ordering

IBS.Selfdestruct emits three versionWritten entries
(IncarnationPath=preInc, SelfDestructPath=true, BalancePath=0). The
parallel writeset path mishandled them in two ways:

  - normalizeWriteSet's completion loop filled missing account fields
    for SD'd addresses via stateReader, round-tripping pre-SD
    Nonce/CodeHash back into the writeset. applyVersionedWrites then
    took the "cleanup-before-recreate" branch instead of pure-delete:
    phoenix stayed in sd.mem with non-zero incarnation, the next
    block's CREATE2 saw a phantom existing account, and execution
    diverged from serial.

  - calc_state.go ApplyWrites processed writes in arrival order, so
    BalancePath=0 (which resets acc.Deleted=false) ran AFTER
    SelfDestructPath=true (which sets Deleted=true). The SD flag was
    silently clobbered, FlushToUpdates routed into the default UPDATE
    branch instead of DeleteUpdate, and the trie kept pre-SD account
    state.

Fix (1): pre-scan writes for SD'd addresses; drop their
Balance/Nonce/Incarnation/CodeHash/Code raw writes AND skip the
completion-loop fallback for them. The writeset for an SD'd address
carries only SelfDestructPath=true, so applyVersionedWrites reaches
the pure-delete branch.

Fix (2): split ApplyWrites into two passes — first applies non-SD
writes, second applies SelfDestructPath. SD wins regardless of
arrival order. The SD pass zeros Balance/Nonce/CodeHash/Incarnation
(matching serial's DomainDel removing the leaf) and zeros every
tracked storage slot so FlushToUpdates emits DeleteUpdate per slot —
required because vm.StorageKeys only returns slots written in the
current tx's version map (Selfdestruct() doesn't write storage
explicitly), so without zeroing here, stale storage values would
survive into the trie post-SD and break TestRecreateAndRewind block 4
(recreate sees stale storage).

Test results
============
All seven Bucket C tests pass under EXEC3_PARALLEL=true with -count=3:
TestBlockchainHeaderchainReorgConsistency, TestLongerForkHeaders,
TestLongerForkBlocks, TestCallTraceUnwind, TestTxLookupUnwind,
TestLowDiffLongChain, TestRecreateAndRewind. make lint clean.

Known follow-up
===============
go test -race flags 8 races inside ComputeCommitment's parallel worker
goroutines — they write commitment branches via the lock-exempt
CommitmentDomain path while the calc's outer Lock is held by the main
goroutine. These are not new functional bugs (origin/main has the same
unsynchronized access pattern; race detector reports 0 there because
those tests fail before the racing access is hit). The clean closure is
to remove the calculator's branch writes from the global accumulator
entirely — see memory project_lock_free_exec_followup.md for the
preferred path (reuse the existing deferCommitmentUpdates/
FlushPendingUpdates infrastructure to defer branch writes out of the
swap window). Tracked as a separate PR; for this PR we want CI
correctness.

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

… conditional Deleted-clearing

Replaces the two-pass (non-SD then SD-wins) approach in 6dc4e3f
with a single pass that conditionally clears acc.Deleted only when
the incoming Balance/Nonce/CodeHash/Code value is non-zero/non-empty.
Functionally equivalent for the off-by-one cluster + recreate; restores
test-source compatibility with the existing
TestApplyWrites_BalancePathClearsDeleted and TestApplyWrites_IncarnationPath
unit tests in execution/stagedsync.

Why
---
6dc4e3f's two-pass refactor changed the order in which writes hit
acc.Deleted such that:

  TestApplyWrites_IncarnationPath: writes [Inc=1, SD=true]
    expected Inc=1 + zero-account-UPDATE flags
    got Inc=0 + DeleteUpdate (because SD-second-pass zeroed Inc)

The unit test's expectation of "Inc preserved → zero-account UPDATE"
was based on a stale comment in calc_state.go that misread serial's
behavior; empirically serial's DomainDel for a pure SD-of-pre-existing
removes the leaf (DeleteUpdate), not a zero-fields-with-Inc encoding
(see TestRecreateAndRewind block 3 expected root). The test is now
updated to match the corrected semantics.

  TestApplyWrites_BalancePathClearsDeleted: writes [SD=true, Bal=42]
    expected Deleted=false + Bal=42

Under the simplified single-pass with conditional Deleted-clearing,
SD sets Deleted=true and zeros fields, then Bal=42 (non-zero) re-sets
Bal=42 and clears Deleted. Test passes unchanged.

Semantics
---------
The two invariants from 6dc4e3f are preserved, just expressed
differently:

  (1) IBS.Selfdestruct's trailing BalancePath=0 must NOT clobber
      Deleted=true. Achieved by gating the Deleted-clearing on a
      non-zero incoming value in BalancePath/NoncePath/CodeHashPath/
      CodePath cases — zero writes are part of the SD emission and
      do not undo Deleted.

  (2) SelfDestructPath=true zeros Balance/Nonce/CodeHash/Incarnation
      and zeros every tracked storage slot, so FlushToUpdates routes
      into the EIP-161 DeleteUpdate branch (matching serial's
      DomainDel removing the leaf).

All seven Bucket C tests still pass under EXEC3_PARALLEL=true with
-count=2; make lint clean.

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