Addresses review feedback from @mriccobene on PR #21017: the QA dashboard
filters results by test_name regex. Without a suffix the parallel and
serial entries land under the same test_name and can't be distinguished
in the Hive UI / Grafana dashboard.

Per the reviewer's preferred convention, leave the serial entry's name
unchanged and add `-parallel` only for the parallel matrix entry. Both
`upload_test_results.py` invocations are updated:

  - qa-rpc-integration-tests-latest.yml:266 →
    rpc-integration-tests-latest[-parallel]

  - qa-rpc-performance-comparison-tests.yml:374 →
    rpc-performance-test-latest[-parallel]-$method

The HDR-analysis PDF test_name (line 340 of the perf-comparison file)
is intentionally left as `$client-$method` — that name only labels a
local report file, which is already disambiguated by the artifact name's
`-${{ matrix.exec_mode }}` suffix.

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

…oop exit (erigontech#21039)

## Summary

Drops the fallback clause in `applyLoopMissingBlocks` that turned every
legitimate partial-batch exit into a spurious `InvalidBlock` error.

When the parallel exec loop hits its size-limit mid-fixture, it returns
nil with `reachedMaxBlock=false`. The previous completeness check
flagged `maxBlockNum` as "missing" whenever `!reachedMaxBlock` — but the
size-limit path is normal: the apply loop returns `ErrLoopExhausted`,
the stage loop resumes the next batch from `lastBlockResult+1`, and each
block still executes exactly once. No re-execution.

## Update — additional fix in commit `310a094514`
(`execution/stagedsync: honor blockResult.Exhausted in exec loop`)

Same class of partial-batch orchestration bug, on the **exec-loop
side**. `executeBlocks` marks the final dispatched block with
`Exhausted` when the per-cycle block limit fires, then exits its
goroutine — without closing `pe.execRequests`, without cancelling ctx.
The exec loop had no branch to react to that signal: after the last
blockResult was applied, the main select parked waiting for
`execRequests` / `rws.ResultCh` / `ctx.Done` — none of which ever fire.
The apply loop never got the channel-close signal it needs to return
`ErrLoopExhausted`, so the original (apply-loop-side) fix in this PR
couldn't even run.

Reproduced as a chiado parallel-exec **silent stall** at block 150662
with `EXEC3_PARALLEL=true ... --sync.loop.block.limit=10_000` from block
0 (issue erigontech#20711). The hang was masking a wrong-trie-root divergence at
the same block — with the exhaust signal honored, the underlying
`ErrWrongTrieRoot` now surfaces cleanly through the apply loop and the
original-issue symptom appears as expected.

The new branch sits between the `maxBlockNum`-reached check and the
`StopAfterBlock` debug exit, matching the precedence of the existing
partial-batch exits.

Tests: `TestExecLoopHonorsBlockResultExhausted` runs **two models** of
the exec-loop blockResult decision tree (post-fix and pre-fix) against
identical channel orchestration. The pre-fix model must hang past the
timeout — proves the test scaffolding genuinely surfaces the bug rather
than passing vacuously. `TestExecLoopExhaustedOnlySetOnFinalBlock` locks
in the dispatcher convention so future `executeBlocks` changes can't
silently drop already-queued work by setting `Exhausted` mid-stream.

## Why

Reproduces deterministically as the parallel-mode `BenchmarkFeeHistory`
failure on PR erigontech#21017 (the CI matrix that runs every test under both
`serial` and `parallel` exec modes):

```
apply loop exited (reachedMaxBlock=false lastBlockResult=114 maxBlockNum=200) but 1 block(s) had tx-results without a blockResult or were never delivered: [200]
```

200 blocks × 100 simple transfers exceed the test fixture's 5MB batch
budget at block 114. Trace confirms:
- Batch 1: blocks 1..114, size-limit fires, `ErrLoopExhausted`
- Batch 2: blocks 115..200, `reachedMaxBlock=true`, clean nil

Sd.mem is not contaminated by in-flight future-block writes —
`txResultBlocks` at exit was exactly `[1..114]`. Block 200 was flagged
solely from the fallback clause.

## Shutdown sequence verified

Tracing the deferred-close in `execLoop`: `commitResults` closes first,
calculator drains and closes `rootResults`, apply loop sees both closes,
drains, runs the completeness check, returns `ErrLoopExhausted`.
`executorCancel` then cancels `execLoopCtx`, `executeBlocks` and workers
exit, `pe.wait` joins. Three batches in `BenchmarkFeeHistory` run
end-to-end with no goroutine leaks.

## Tests

* `TestApplyLoopMissingBlocks` — adds a "partial batch — size-limit hit,
no spurious flag for unreached blocks" case
* `TestApplyLoopPartialBatchReturnsErrLoopExhausted` — exercises the
apply-loop exit decision tree (exhausted vs nil vs InvalidBlock) for
partial-batch / full-batch / silent-failure scenarios
* `TestApplyLoopChannelCloseOrder` — pins the load-bearing
`commitResults`-before-`applyResults` close order
* `TestExecLoopHonorsBlockResultExhausted` — orchestration test for the
exec-loop side of the partial-batch exit (added in commit `310a094514`)
* `TestExecLoopExhaustedOnlySetOnFinalBlock` — pins the executeBlocks
dispatcher convention (added in commit `310a094514`)

## Test plan

- [x] `BenchmarkFeeHistory/full/blocks=200` passes with
`ERIGON_EXEC3_PARALLEL=true`
- [x] `make lint` clean
- [x] `go test -race ./execution/stagedsync/...` for new tests passes
- [x] Existing `TestApplyLoopRootResultsCloseDoesNotRace`,
`TestApplyLoopDoesNotHangAfterRootResultsClose`,
`TestExecLoopExitCheck*` still pass
- [x] Chiado `EXEC3_PARALLEL=true ... --chain=chiado
--sync.loop.block.limit=10_000 --prune.mode=archive` from block 0
reaches the underlying `ErrWrongTrieRoot` at block 150662 instead of
silently stalling (verifies the partial-batch exec-loop exit fires)

## CI fix linkage

Precursor for erigontech#21017 (CI matrix `exec_mode={serial,parallel}`). Without
this, `bench / benchmarks (parallel)` and any other workflow exercising
a chain large enough to cross the batch-size boundary fails on first
crossing. Companion to erigontech#21032 (incarnation/SD differentiator fix).

…tyRemoval (erigontech#21032)

## Summary

Fixes a wrong trie-root in the parallel commitment calculator when
post-tx writesets are indistinguishable between two cases:

1. **SELFDESTRUCT of a pre-existing contract** — serial keeps the leaf
with `incarnation>0`, zero balance/nonce/empty codeHash. Parallel was
emitting `DeleteUpdate` and removing the leaf.
2. **EIP-161 emptyRemoval** of a touched-empty account (e.g. `0xff…fe`
after the EIP-4788 system call) — serial emits `DeleteUpdate`. Parallel
was emitting a zero-account UPDATE.

The discriminator is the **pre-block incarnation**, which the writeset
alone didn't carry. Fix wires it through `LightCollector.DeleteAccount`
→ `IncarnationPath` write → `calcAccountState.Incarnation` → 3-way
branch in `FlushToUpdates`.

## Dependency direction

This PR is a **precursor for erigontech#21017** (the CI matrix that runs every
test under both `serial` and `parallel` exec modes). Without this fix,
parallel-mode tests on hive `rpc-compat`, `engine
api/cancun/withdrawals`, and the eest selfdestruct sub-suites all fail
with wrong-trie-root errors at SD/empty-removal blocks. **erigontech#21017 cannot
land until this PR lands.**

The matrix in erigontech#21017 will validate this PR end-to-end via the hive
parallel sub-suites — meaning this PR's parallel-exec changes don't run
in *this* PR's own CI, only in erigontech#21017's. The rebased erigontech#21017 is the
meaningful go/no-go signal.

## Changes

* `LightCollector.DeleteAccount` now emits `IncarnationPath` alongside
`SelfDestructPath=true` when `original.Incarnation > 0`. Calc receives
the pre-deletion incarnation through the same channel as every other
write — no exec-side state leakage.
* `calc_state.ApplyWrites` consumes `IncarnationPath` into
`calcAccountState.Incarnation` via direct type-assertion (panic on
mismatch — see *Concern 3* below).
* `calc_state.FlushToUpdates` switches on a 3-way `Deleted` branch with
`isAllZero` defense-in-depth:
* `Deleted && Incarnation>0 && all-zero` → zero-account UPDATE (matches
serial's `DomainDel`-leaves-post-CREATE-encoding for SD'd contracts)
* `Deleted && all-zero && Incarnation==0` → `DeleteUpdate` (matches
serial's `DomainDel`-truly-empties for EIP-161 emptyRemoval)
* `Deleted` with retained non-zero values → regular UPDATE — defensive
coverage for OOG-CREATE2-with-retained-balance and any future
write-ordering race
* `SelfDestructPath` also marks all tracked storage slots dirty so
`FlushToUpdates` emits per-slot updates alongside the account reset.
Load-bearing invariant: `normalizeWriteSet`'s `vm.StorageKeys(addr)`
loop emits `StoragePath=0` entries that arrive in `ApplyWrites` after
`SelfDestructPath`, overwriting the marked slots' values to zero so they
emit `DeleteUpdate` not `StorageUpdate(pre-SD value)`. Inline comment in
`calc_state.go` spells this out — see *Concern 2* below.

## Earlier draft snags (resolved)

The first draft also added an `IncarnationPath > 0` exclusion to
`normalizeWriteSet`'s empty-account check. This was **redundant** (the
empty-check already requires `Nonce == 0`, which excludes successful
CREATE/CREATE2) and **broke OOG-during-CREATE2 cases** (which leave
`Nonce=0/Balance=0/Code=empty/Incarnation=1` and *must* still be
deleted). Removed in `9539998f14`. The `exec3_parallel.go` diff in this
PR is now comments-only.

## Reviewer concerns addressed

### #1 (yperbasis): PR description was stale

This body. ✓

### #2 (yperbasis + Copilot): SD storage-cascade load-bearing invariant

Inline comment in `calc_state.go`'s `SelfDestructPath` case now spells
out the dependency on `normalizeWriteSet`'s `vm.StorageKeys(addr)` loop.
✓

### #3 (yperbasis + Copilot): IncarnationPath guarded type-assertion

Changed to direct `w.Val.(uint64)` to match the other paths. Silent zero
would route a real SD into the EIP-161 branch and reproduce the very
wrong-root bug — better to panic at the source. ✓

### #4 (yperbasis):
`TestFlushToUpdates_DeletedWithRetainedBalance_EmitsRegularUpdate`
docstring

Updated to clarify: this is **defensive coverage** for the third
`FlushToUpdates` branch in isolation, NOT a direct repro of the
eest_devnet OOG path. The actual OOG fix is the removal of the redundant
`IncarnationPath > 0` clause from `normalizeWriteSet` (the OOG writeset
has `Nonce=0` → empty-account → `DeleteUpdate`, not
`Deleted+RetainedBalance`). End-to-end coverage of that path lives in
the eest_devnet suite, surfaced via erigontech#21017's matrix. ✓

### #5 (yperbasis): `versionedWriteCollector.DeleteAccount` asymmetry —
*intentional non-fix*

Decision: **keep the asymmetry, document why.** Inline comment added on
`versionedWriteCollector.DeleteAccount` explaining:

* It's wired only into `txResult.finalize` (fee calc + post-Cancun
system calls).
* Neither path SDs a pre-existing contract today, so the
SD-with-incarnation differentiator is unreachable from here.
* If a future caller ever does emit `DeleteAccount` on a pre-existing
contract through this collector, the comment flags that this code should
mirror `LightCollector.DeleteAccount`'s `IncarnationPath` emit.

Adding the emit speculatively was rejected because: (a) it changes the
writeset shape for paths that today don't need it, (b) any test
exercising the new emit would be vacuous since no production caller hits
the `original.Incarnation > 0` branch, and (c) the comment is enough to
attribute the bug at first sight if someone *does* reach that code path
in the future.

## Intentional non-fixes

* **Concern #5 above** — `versionedWriteCollector.DeleteAccount` left
without the `IncarnationPath` emit (rationale above).
* **Defensive `TestFlushToUpdates_DeletedWithRetainedBalance` test
kept** despite the state being unreachable from real LightCollector
writesets today — protects the FlushToUpdates branch in isolation
against future ApplyWrites refactors that might drop the
`BalancePath`-clears-`Deleted` invariant.

## Test plan

- [x] All 6 unit tests in `calc_state_test.go` pass
(`TestFlushToUpdates_DeletedWithIncarnation_EmitsZeroAccountUpdate`,
`TestFlushToUpdates_DeletedWithoutIncarnation_EmitsDelete`,
`TestFlushToUpdates_DeletedWithRetainedBalance_EmitsRegularUpdate`,
`TestFlushToUpdates_LiveAccount_EmitsFullUpdate`,
`TestApplyWrites_IncarnationPath`,
`TestApplyWrites_BalancePathClearsDeleted`)
- [x] eest_devnet
`for_amsterdam/constantinople/eip1052_extcodehash/extcodehash/extcodehash_subcall_create2_oog`
all 6 variants pass locally
- [x] Full `for_amsterdam/constantinople` eest_devnet suite passes
- [x] `make lint` clean
- [x] CI on `9539998f14` was green

End-to-end validation comes via erigontech#21017's CI matrix once it rebases on
top of this PR.

…ComputeCommitment swap

Closes ~93% of the race-detector hits surfaced on #21017's parallel
race-test matrix by extending the changesetMu band-aid (added in the
prior commit) to cover the deferred-update flush window and the
ComputeCommitment internal [state] marker write.

Race count delta (parallel race-tests groups):

  Group                     Before  After  Δ
  ----------------------- -------  -----  -----
  execution-other              12      2  -83%
  core-rpc                    158     13  -92%
  execution-eest-blockchain     4      0  -100%
  Bucket C cluster              4      0  -100%

What changed
------------

* `SharedDomains.FlushPendingUpdates` previously did its inner swap
  (`switcher.SetChangesetAccumulator(cs)` … restore) directly via the
  `changesetSwitcher` interface, bypassing changesetMu. The race
  detector flagged this as the dominant race signature
  (SetDiff↔SetDiff, SetChangesetAccumulator↔SetChangesetAccumulator,
  GetChangesetAccumulator↔SetChangesetAccumulator).

  Split into `FlushPendingUpdates` (acquires changesetMu) and
  `FlushPendingUpdatesLocked` (caller already holds it). The internal
  `flushPendingUpdates(lockHeld bool)` is the single implementation.

* Added `ComputeCommitmentLocked` for the parallel calculator's
  per-block compute window. The calc holds changesetMu via
  `LockChangesetAccumulator` and now calls `ComputeCommitmentLocked`
  which uses `FlushPendingUpdatesLocked` instead of the public flush.

* The `cs == nil` early-return path in `computeWithBlockAccumulator`
  also takes the lock now — the FlushPendingUpdates inside
  ComputeCommitment still runs there and needs serialization against
  the apply-side SetChangesetAccumulator. Without this the cs==nil
  fast path produces ~73 SetDiff vs PutWithPrev hits per group.

* Added `domainPutNoLock` as an internal helper used by
  FlushPendingUpdates' deferred-branch replay, since
  `SharedDomains.DomainPut` for non-CommitmentDomain takes the lock
  and would self-deadlock when the caller already holds it.

Bucket C functional tests (no -race) still all pass under
EXEC3_PARALLEL=true. make lint clean.

Residual races (~2 per execution-other run) are
encodeAndStoreCommitmentState's [state] marker write going through
the lock-exempt CommitmentDomain branch in DomainPut — closing those
needs the [state] marker write to also be deferred (or the
exemption removed). Tracked as Variant 1 / lock-free follow-up in
the parallel-exec hardening series.

This commit is intended to fold into #21088 since it's a related fix
on the same band-aid mutex and #21088 hasn't been reviewed yet.

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

Addresses review feedback from @mriccobene on PR #21017: the QA dashboard
filters results by test_name regex. Without a suffix the parallel and
serial entries land under the same test_name and can't be distinguished
in the Hive UI / Grafana dashboard.

Per the reviewer's preferred convention, leave the serial entry's name
unchanged and add `-parallel` only for the parallel matrix entry. Both
`upload_test_results.py` invocations are updated:

  - qa-rpc-integration-tests-latest.yml:266 →
    rpc-integration-tests-latest[-parallel]

  - qa-rpc-performance-comparison-tests.yml:374 →
    rpc-performance-test-latest[-parallel]-$method

The HDR-analysis PDF test_name (line 340 of the perf-comparison file)
is intentionally left as `$client-$method` — that name only labels a
local report file, which is already disambiguated by the artifact name's
`-${{ matrix.exec_mode }}` suffix.

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

…eorg/unwind + SD recreate (erigontech#21088)

## Summary

Closes the off-by-one wrong-trie-root cluster, `TestRecreateAndRewind`,
and **all** `TemporalMemBatch.currentChangesAccumulator` /
`DomainBufferedWriter.diff` race-detector hits surfaced on erigontech#21017 under
`EXEC3_PARALLEL=true`. Six commits:

1. `8c9d9c10a7` — Per-block commitment in calculator when generating
changesets
2. `acba3279a6` — Lock `pastChangesAccumulator` for parallel-commitment
access
3. `bac3ee0c25` — Hash-aware past-changeset lookup for parallel
calculator
4. `6dc4e3fe8f` — Serialize accumulator swap; SD-aware writeset
normalization
5. `980de89157` — Simplify calc SD `ApplyWrites` — single pass with
conditional `Deleted`-clearing
6. `29f5ebc2ed` — Lock-protect `FlushPendingUpdates` +
`ComputeCommitment` swap (closes 100% of the dominant race signature)

### Functional fix (commits 1–5)

- **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. During that swap window, the apply goroutine's
`DomainPut` for block N+1's account/storage writes was landing in block
N's CS, causing missing prev-value entries on unwind
(`TestBlockchainHeaderchainReorgConsistency`,
`TestLongerForkHeaders/Blocks`, `TestCallTraceUnwind`).
- **SD-aware writeset normalization.** `IBS.Selfdestruct` emits three
writes (`IncarnationPath`, `SelfDestructPath=true`, `BalancePath=0`).
`normalizeWriteSet`'s completion loop was filling missing fields for
SD'd addresses via the stateReader, round-tripping pre-SD nonce/codeHash
back into the writeset. `applyVersionedWrites` then took the
cleanup-before-recreate branch instead of pure-delete, so phoenix stayed
in `sd.mem` with non-zero incarnation and the next block's `CREATE2` saw
a phantom existing account. Calc-side `ApplyWrites` also had the
symmetric bug: the trailing `BalancePath=0` clobbered `Deleted=true` set
by `SelfDestructPath`. Fix: drop SD'd addresses' raw account-field
writes in normalize; in calc, gate `Deleted`-clearing on a non-zero
incoming value, and zero `Balance`/`Nonce`/`CodeHash`/`Incarnation` and
storage on `SelfDestructPath`.

### Race fix (commit 6)

The band-aid mutex from commit (4) only covered the calculator's outer
swap and apply-side `DomainPut`/`DomainDel`. `FlushPendingUpdates`
(which runs inside `ComputeCommitment`) was doing its own inner swap via
the `changesetSwitcher` interface, bypassing `changesetMu`. That left
the dominant race signature in erigontech#21017's parallel race-tests open (227
hits across the four matrix groups, all in the
`currentChangesAccumulator` / `DomainBufferedWriter.diff` family).

Commit (6) splits `FlushPendingUpdates` into the public locking variant
and an unlocked `FlushPendingUpdatesLocked` for the calc, adds
`ComputeCommitmentLocked` for the calc's per-block compute window, and
extends the calculator's outer lock to the `cs == nil` early-return path
so the inner `FlushPendingUpdates` is always serialized against the
apply loop.

| Race-tests group | Baseline races | After this PR | Δ |
|---|---:|---:|---:|
| execution-tests | 53 | **0** | -100% |
| execution-other | 12 | **0** | -100% |
| core-rpc | 158 | **0** | -100% |
| execution-eest-blockchain | 4 | **0** | -100% |
| Bucket C cluster (under -race) | 4 | **0** | -100% |
| **Total** | **231** | **0** | **-100%** |

## Test plan

- [x] All seven Bucket C tests pass under `EXEC3_PARALLEL=true`
`-count=2`:
  - `TestBlockchainHeaderchainReorgConsistency`
  - `TestLongerForkHeaders` / `TestLongerForkBlocks`
  - `TestCallTraceUnwind`
  - `TestTxLookupUnwind`
  - `TestLowDiffLongChain`
  - `TestRecreateAndRewind`
- [x] Bucket C cluster under `-race` shows 0 races (was 4 before this
PR).
- [x] All four parallel race-tests matrix groups under `-race` show 0
races (was 227 before this PR).
- [x] `make lint` clean.
- [x] No regressions in the surrounding parallel-exec test groups.

## Known follow-ups (NOT in scope for this PR — separate parallel-exec
hardening track)

- **Functional test failures unrelated to commitment-accumulator races**
remain in some parallel-mode test groups (~20 unique tests across
core-rpc, execution-other, etc.). These are NOT race-detector hits —
they're pre-existing functional issues unrelated to the
commitment-accumulator fixes (engine-API behavior, RPC test fixtures,
etc.). Tracked as separate follow-up PRs in the parallel-exec hardening
series.
- **`stage-exec-test (from-0, parallel | serial)` and `(chaintip,
parallel | serial)`** — failures span both modes, indicating a
non-Bucket-C concern. Separate PR.
- **Lock-free execution refactor** (Variant 1 / Option A0 in the
project's session memory) — eventually delete the `changesetMu` band-aid
and the swap dance in `committer.go computeWithBlockAccumulator` by
deriving per-block changesets post-hoc from sd entries at flush time.
Architectural rather than band-aid.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

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