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

…rgs) (erigontech#21211)

## Summary

First incremental cut toward
[erigontech#21138](erigontech#21138 structural
goal: **one finalize function per parallel-exec result, with
`IntraBlockState` used nowhere outside workers**.

This PR removes two finalize variants that are already unreachable from
production:

| Function | LOC | Production callers on main |
|---|---|---|
| `finalizeWithIBS` (full IBS reconstruction, BAL-compat path) | ~120 |
0 |
| `finalizeTx` (delta-args variant, direct fee-balance path) | ~250 | 0
(only `TestFinalizeTx_AllScenarios`) |

Plus the test suite that exclusively exercised the delta-args path
(`TestFinalizeTx_*`, fixture builders `coinbaseIsRecipientScenario` /
`selfTransferScenario`, helpers `hasCoinbaseDelta` /
`adjustForTransferDelta` / `buildWriteMap` / `fmtWriteVal` /
`extractBalanceReads`) and one stale comment in
`engine_api_bal_test.go`.

Net: **-690 lines**, **+1 line**, no semantic change.

## Why now

The parallel-exec correctness stack landed in erigontech#21153 (merged
2026-05-15). The combined effect of that PR plus erigontech#21177 routed all
production finalize flows through `finalizeTxSimple` — these two
functions became unreachable. Removing them shrinks `exec3_parallel.go`
from 3640 → 3268 lines, making subsequent IBS-dependency drains easier
to review.

The next steps in the erigontech#21138 sequence:

- **PR 2** — drain IBS dependency #1 (SD address lookup):
`LogSelfDestructedAccounts` consumes `result.SelfDestructedWithBalance`
only, no `ibs.GetRemovedAccountsWithBalance()` call.
- **PR 3** — drain IBS deps #2 (`AddLog` → return logs) and #3
(`AddBalance` bookkeeping → already on `CollectorWrites`);
`finalizeTxSimple` becomes IBS-free.
- Later — `normalizeWriteSet` → `filterWritesByVersionMap`;
`calcState.ApplyWrites` → `VersionedWrites.TouchUpdates`; move
EIP-7002/7251 syscall execution into the worker pool.

End state: one `finalizeTx`, no IBS outside workers.

## Test plan

- [x] `make lint` clean
- [x] `make test-short` (full `execution/stagedsync`, `execution/state`,
`execution/tests`, `rpc/jsonrpc` packages) green under
`EXEC3_PARALLEL=true`
- [x] BAL family (`TestEngineApiBAL*`) 8/8 parallel
- [x] `TestEIP7708BurnLogWhenCoinbaseSelfDestructs` green
- [x] Surviving `TestFinalizeTxSimple_*` family green
- [ ] CI: race-tests, kurtosis, hive matrix legs green on both serial
and parallel

## Related

- erigontech#21017 — serial/parallel CI matrix that surfaces parallel-leg failures
(now rebuilt on post-erigontech#21153 main; CI fresh-running)
- erigontech#21153 — parallel-exec correctness stack (merged)
- erigontech#21138 — heuristic-removal / IBS-dependency-removal tracker (the
parent)

…ckly (erigontech#21483)

## Problem

When a merge-queue run has a hive-eest shard fail, the failing job calls
`gh run cancel ${{ github.run_id }}` (added in erigontech#21445). That sends
SIGTERM to all in-flight matrix siblings, but the Docker-bound hive
simulators take ~20 minutes to actually drain. `ci-gate` is `if:
always()` and waits for every `needs` job to reach a terminal state, so
the broken PR sits at `AWAITING_CHECKS` for the full drain time —
blocking the head of the merge queue.

Concrete example from today (PR erigontech#21470 at position #1):

- 08:29:57 — `hive-eest / test-hive-eest (paris+shanghai, serial)`
fails, calls `gh run cancel 26562610423`, emits the "Merge-queue
root-cause failure" annotation from erigontech#21445.
- 08:48 (~19 min later) — paris+shanghai-parallel,
prague-serial/parallel, cancun-serial/parallel, osaka-parallel,
rlp-serial/parallel, and glamsterdam-devnet-parallel were all still
`in_progress`. Every other ci-gate child (tests, race-tests,
eest-spec-tests, kurtosis, hive, lint, bench, repro, sonar, caplin) had
already completed.

The bottleneck was specifically the hive-eest matrix siblings.

## Fix

```yaml
strategy:
  fail-fast: ${{ github.event_name == 'merge_group' }}
```

- **In `merge_group`**: first failed shard immediately cancels all
siblings at the GitHub API layer — much faster than the `gh run cancel`
→ SIGTERM → runner-drain path. ci-gate's `needs` reach terminal state in
seconds, ci-gate fails, the broken PR is evicted.
- **In PR runs**: stays `false`, so authors still see the full failure
breakdown across every shard. No regression in PR feedback.

## What's left in place and why

The per-job `gh run cancel` step (test-hive-eest.yml lines 311-317)
stays. Two reasons:

- Matrix `fail-fast` only cancels siblings **within the same matrix** —
it doesn't cancel sibling reusable workflows. If a future failure
pattern leaks across workflows, `gh run cancel` still covers it.
- ci-gate.yml's root-cause annotator (line 188) keys off "the leaf that
ran `gh run cancel` successfully" to single out the true root cause
among collateral cancellations. Removing the step would silently regress
erigontech#21445's attribution.

## Scope choice

Only `test-hive-eest.yml` is changed. Other matrix-bearing reusable
workflows (`test-all-erigon.yml`, `test-all-erigon-race.yml`,
`test-eest-spec.yml`, `test-kurtosis-assertoor.yml`, `test-hive.yml`,
`test-bench.yml`) all use `fail-fast: false` too, but none of them were
the queue-blocking long pole in this incident. Keeping the patch
minimal; we can generalize if another workflow becomes the bottleneck.

## Tradeoff to be aware of

Queue runs will now show siblings as `cancelled` instead of `failed`
whenever any one shard fails. That's the correct tradeoff in
`merge_group` — the goal is fast eviction, not detailed diagnostics;
full per-shard breakdown remains available on the PR run.

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

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

…#21579)

Two tweaks to how Claude Code operates in this repo.

## 1. Bare `#N` references in GitHub text

Claude has used a bare `#`+number to mean "point N" — e.g. writing
"`#1`" for "the nit from point 1" — in PR descriptions, issue
descriptions, and comments. GitHub auto-links that to the issue/PR with
that number, so "`#1`" turns into a link to the repo's first-ever PR.
This came up in [PR
21510](erigontech#21510 (comment))
and has happened on other occasions.

`agents.md` now instructs Claude to write "point 1" / "item 1" / "the
first nit" and reserve `#N` for genuine issue/PR references.

## 2. Claude attribution in commits, PRs, and issues

Stop adding `Co-Authored-By: Claude` and `🤖 Generated with Claude Code`
lines.

Enforced deterministically in `.claude/settings.json` rather than as a
prose instruction, so it does not depend on the model remembering:

- `includeCoAuthoredBy: false` — the one switch the installed Claude
Code (v2.1.160) honors across *both* the commit and PR code paths; it
returns empty attribution for each.
- `attribution: { commit: "", pr: "" }` — the newer, forward-looking
mechanism; empties the footer text.

**Why both:** `attribution` alone is insufficient today — the PR code
path does a truthy check on `attribution.pr`, so an empty string is
ignored and the "Generated with" footer still leaks into PR bodies.
`includeCoAuthoredBy: false` is the reliable global off-switch.
`agents.md` documents the rule for human readers too.

---

Docs/config only — no Go changes, so build/lint are unaffected. This PR
follows both rules itself: no attribution trailers on the commit, and
the `#1` examples above are shown as code so they don't auto-link.

…LOAS (erigontech#21698)

## Problem

Lido Hoodi validators lost attestation score after switching to
`release/3.5`. They missed **head votes** at ~30–60% per epoch (≈2× a
random network sample) while **target and source votes were always
correct** — the attestations were produced, published, and included
on-chain on time, but voted for a **stale head**.

## Root cause

The GLOAS merge (erigontech#18956) added `indexedWeightStore`
(`cl/phase1/forkchoice/weight_store_indexed.go`). It is instantiated
unconditionally, and its `IndexVote`/`RemoveVote` are called per
validator index on **every** attestation via `setLatestMessage`,
regardless of fork.

However its results are only consumed by GLOAS `get_head`. Pre-GLOAS
`get_head` (and `timing.go`) use the non-indexed `weightStore`, and
`GetIndexedWeightStore()` has no callers. So on pre-GLOAS chains the
index is maintained but never read.

On a high-validator-count network (Hoodi, ~1.2M active validators) this
maintenance was the single largest CPU consumer (`RemoveVote`, ~15% of
CPU, fresh slice allocation per call) plus a large GC load — all under
the fork-choice write lock. The lock contention delayed `OnBlock` (block
import) and `get_head` past the attestation deadline, so the head served
to the validator client was stale → wrong head votes.

## Fix

Gate the indexed-store maintenance to the GLOAS vote path only, via an
explicit `maintainIndexedVotes` flag on `setLatestMessage` (mirroring
the existing `updateLatestMessages` pre-GLOAS/GLOAS dispatch).

## Validation (live Hoodi node, before vs after rebuild)

- Node CPU (operator Grafana): ~7.5% → <2%.
- 60s CPU profile: total samples 148.9% → 41.6%;
`indexedWeightStore.RemoveVote` (was #1 hotspot) and the GC storm both
gone.
- Head-at-attestation-deadline staleness: 64% → 4%.
- Validator head-vote misses: 40% → 0% in the first fully post-fix epoch
(network sample ~23% in the same epoch); target/source unaffected
throughout.

Affects all pre-GLOAS networks on this branch (mainnet/Sepolia/Gnosis),
with impact scaling by validator count.

## Tests

- `TestPreGloasDoesNotMaintainIndexedWeightStore` — fails before the fix
(the pre-GLOAS path populates the index), passes after.
- `TestGloasMaintainsIndexedWeightStore` — locks in that the GLOAS path
still indexes votes.
- `go test ./cl/phase1/forkchoice/...`, `make lint`, `make erigon` all
clean.

## Follow-up

`indexedWeightStore` is currently unused even on GLOAS (`get_head` uses
the non-indexed store). The Caplin team should either wire it into GLOAS
`get_head` or remove it; tracking separately.