…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.

…igontech#21017)

> **2026-05-15 — erigontech#21153 has merged.** The companion PR carrying the
substantive parallel-exec correctness + perf fix family
(`mh/parallel-exec-fixes`, merged 2026-05-15 02:35Z as `958b2fbb85`) is
now on `main`. This PR has been rebased onto fresh main; the trimmed
branch contains only the serial/parallel exec-mode CI matrix yamls plus
two CI hygiene fixes (a shared `build-erigon-image` job for the kurtosis
matrix, and the `setup-erigon` apt-mirror flake fix), plus three
workflow follow-ups from the 2026-05-13 review.
>
> **Landed precursors:**
> - ✅ erigontech#21153 (merged 2026-05-15) — parallel-exec correctness/perf stack
split from this PR
> - ✅ erigontech#21088 (merged 2026-05-10) — parallel-commitment correctness for
reorg/unwind + SD recreate
> - ✅ erigontech#21032 (merged 2026-05-08) — wrong-trie-root on Cancun / SD paths
> - ✅ erigontech#21039 (merged 2026-05-08) — apply-loop completeness false-flag on
partial-batch exit
> - ✅ erigontech#21010 (merged 2026-05-07) —
`commitmentCalculator.asOfReader.txNum=0` lazy-load fix
>
> Open follow-up issues (separate from this PR's scope): erigontech#21106
(parallel-exec hardening), erigontech#21107 (stage-exec `from-0`/`chaintip`),
erigontech#21108 (residual `EXEC3_PARALLEL` functional cases), erigontech#21136 (gated
SkipLoads), erigontech#21138 (heuristic-removal structural cleanup).

## Summary

Adds an `exec_mode: [serial, parallel]` matrix axis to every CI test
workflow that exercises the EL execution path so divergence between
`dbg.Exec3Parallel` true and false is caught on the PR rather than after
release.

The toggle is plumbed via `ERIGON_EXEC3_PARALLEL` — `envLookup` in
[common/dbg/dbg_env.go:38](common/dbg/dbg_env.go#L38) auto-prepends the
`ERIGON_` prefix to the source-side `EXEC3_PARALLEL` flag in
[common/dbg/experiments.go:81](common/dbg/experiments.go#L81).

## Why

`Exec3Parallel = false` is currently the source default on `main`. With
no CI workflow setting the env var, every CI run today exercises only
the **serial** path. The parallel path lands via `--bal` chains and
tests like `experimentalBAL`, but the broad correctness signal (unit /
race / hive / kurtosis / RPC integration) is single-mode. This PR makes
both modes a per-PR signal.

## Affected workflows

**Always-on** (matrix on every PR / dispatch / call):

| Workflow | Runner | Parallelism | Cost |
|---|---|---|---|
| test-all-erigon.yml | GitHub-hosted (per-OS) | true parallel |
wall-clock unchanged, +1× runner-min |
| test-all-erigon-race.yml | GitHub-hosted | true parallel | same |
| test-hive.yml | hive group | parallel if pool has slots | same (group
is sized) |
| test-hive-eest.yml | hive group | parallel if pool has slots | same |
| test-kurtosis-assertoor.yml | `ubuntu-latest` | true parallel | same |

**Auto-fire on PRs touching their own YAML, dispatch otherwise** (so
regular PRs don't pay the cost; this PR triggers each one once for
end-to-end validation):

| Workflow | Notes |
|---|---|
| test-bench.yml | `go bench` |
| qa-rpc-integration-tests-latest.yml | self-hosted single-pool,
`max-parallel: 1` (shared testbed state) |
| qa-rpc-performance-comparison-tests.yml | erigon runs serial+parallel,
geth single-mode (placeholder ignored) |
| qa-txpool-performance-test.yml | kurtosis txpool, `max-parallel: 1` |
| qa-stage-exec.yml | 3 mode_names × 2 exec_modes = 6 entries |

**Skipped** — `test-integration-caplin.yml` runs `cl/spectest` only,
doesn't exercise the EL exec path; matrix-doubling would just re-run
identical CL tests.

## Plumbing details

* Workflows that build erigon and run go tests directly: env var set on
the test step's `env:` block.
* Hive-based workflows: an `ENV ERIGON_EXEC3_PARALLEL=...` line is
appended to `clients/erigon/Dockerfile` during the existing sed-patch
loop so every hive-launched erigon inherits the toggle.
* Kurtosis-based workflows: a single upstream `build-erigon-image` job
builds `test/erigon:current-base` once for the whole matrix and uploads
it as a run-scoped artifact; each matrix entry downloads + `docker
load`s and adds a cheap `ENV ERIGON_EXEC3_PARALLEL=…` layer on top to
produce `test/erigon:current`. Avoids ~12 concurrent buildx jobs all
writing the same `type=gha` cache scope and 504-ing.
* Self-hosted single-pool workflows use `max-parallel: 1` to serialize
matrix entries cleanly when state on the runner box is shared (testbed
datadir, reference datadir, etc.).
* All artifact / enclave / testbed-dir names are disambiguated by
`exec_mode` so the two matrix entries don't clobber each other's
outputs.

## Review follow-ups (2026-05-15 rebuild)

After rebasing onto post-erigontech#21153 main, three workflow fixes from the
2026-05-13 review are applied as separate commits on top of the 4
trimmed CI commits:

| Commit | Fixes |
|---|---|
| `ci: gate parallel-suffix QA test_name on client==erigon` | yperbasis
Blocker 2 + Copilot thread #4 — geth's placeholder `exec_mode: parallel`
previously caused its Grafana `test_name` to gain a stray `-parallel-`
suffix, breaking historical dashboard queries |
| `ci: align test-hive devp2p sim-limit between serial and parallel
matrix legs` | yperbasis nit 5 + Copilot threads #3/#9 — both legs now
run `sim-limit: eth` (discv5 doesn't exercise the EL exec path; matches
the long-standing comment) |
| `ci: fix Targetting typo in test-hive-eest.yml` | Copilot thread #6 —
s/Targetting/Targeting/ |

The yperbasis Blocker 1 (`cmd/integration/commands/stages.go:631`
ignores `ERIGON_` prefix, so `qa-stage-exec`'s serial entry silently
runs in parallel mode) is a Go change, raised as a separate small PR to
keep this one strictly `.github/` only.

## Test plan

This PR's CI run **is** the test. The 5 always-on workflows fire
automatically on PR. The 5 perf workflows auto-fire because their
`pull_request: paths` filter matches the workflow's own YAML — so
opening this PR triggers all 10 affected workflows.

What to look for in this PR's "Checks" tab:
- [x] Each affected workflow has both `serial` and `parallel` matrix
entries listed.
- [x] Job display names show the mode (e.g. `tests-mac-linux
(ubuntu-24.04, parallel)`).
- [x] Wall-clock for hosted-runner workflows is essentially unchanged
from main baseline (jobs ran concurrently on separate runners).
- [x] Self-hosted single-pool workflows show ~2× wall-clock (matrix
entries serialize).
- [x] Both modes pass on every workflow. **If serial fails where
parallel passes (or vice versa), that's a real regression we'd want to
catch — exactly the point of this change.**

After merge, regular PRs only pay the matrix cost on the 5 always-on
workflows; the 5 perf workflows go back to being dispatch /
schedule-only.

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: taratorio <94537774+taratorio@users.noreply.github.com>
Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: milen <taratorio@users.noreply.github.com>