…mate

Apply loop's FlushVersionedWrites was called with `cntInvalid == 0` as the
`complete` flag. That counter only tracks *prior* VersionTooEarly txs in the
current iteration - it does NOT include the current tx's own VersionInvalid
verdict. An invalidated tx's writes were flushed as Done and became visible
to downstream OCC readers as committed phantom state.

Symptoms observed before this fix:
- Intermittent wrong-trie-root failures during from-genesis parallel sync
- Gnosis Pattern-2 family gas-mismatches on DEX strategy contracts in the
  14.8M-18.5M block range
- Captured deterministically at gnosis block 18,483,405: tx[3] inc=0
  flagged Invalid, but its slot-write to 0x18b2b767...:0x08 was flushed as
  Done. tx[16] read the phantom via MapRead, validated against matching
  readVersion (version-only check passes), committed phantom-derived state.
  Cascaded gas-mismatch surfaced ~80K blocks later.

Fix: gate the `complete` flag on `valid && cntInvalid == 0` via a new
applyLoopFlushAsComplete helper. An invalidated tx now flushes as Estimate,
which causes downstream reads of those cells to return MVReadResultDependency.
The validator treats those as VersionInvalid, forcing the dependent tx to
re-execute after the retry settles - restoring OCC's "Done = committed"
invariant.

Companion clarity changes:
- exec3_parallel.go: read txVersion from txResult.Task.Version() (the
  *taskVersion wrapper that carries the current Incarnation) instead of
  bare TxTask which always returns Incarnation=0.
- txtask.go: drop dead TxTask.Incarnation field. Live source of truth is
  the txIncarnations counter plus the taskVersion wrapper.

Tests: TestApplyLoopFlushAsComplete covers the helper truth-table including
the regression guard. TestApplyLoopFlush_InvalidTxWritesAreEstimate drives
the production helper through a VersionMap and asserts downstream reads
return MVReadResultDependency (not MVReadResultDone).

Verification: gnosis oracle CHECK swept 18.46M-18.70M+ end-to-end with zero
STATE-ORACLE-DIVERGENCE events. Current from-genesis resync past historical
fail blocks 14.84M, 14.85M, 16.42M without recurrence.

Needs to be merged before 3.5 is cut.

Drop the verbose comment block above the FlushVersionedWrites call site -
the applyLoopFlushAsComplete helper documents the gating itself. Tighten
both function-level comments to focus on the WHY without referencing the
gnosis block number / test name (those belong in the commit message).
Restore applyLoopMissingBlocks back to its original position above
applyLoopFlushAsComplete so its docstring is no longer stranded between
two unrelated functions.

No behavior change.

…imate read

calcFees uses versionedStateReader to fetch coinbase pre-state for the
EIP-161 empty-removal check. versionedStateReader only honours Done
floors and treats MVReadResultDependency (Estimate-flagged prior writes)
as "not found", so coinbaseAcc becomes nil when a prior tx has an
in-flight write to any coinbase account-state path. For zero-tip system
txs that flipped coinbaseEmptyPre to true, calcFees emitted a bogus
SelfDestructPath=true into the validated write set, which then
propagated into the commit channel and the commitment trie -> wrong
trie root.

Pre-21591 this was masked: invalid-tx writes were flushed as Done, so
the vsReader saw the phantom balance and coinbaseEmptyPre stayed false.
With the OCC flush fix in 221007e, invalid-tx writes are correctly
flushed as Estimate, and this latent calcFees defect surfaced as an
intermittent EEST regression on
test_valid_multi_type_requests[fork_Prague-blockchain_test-withdrawal_from_eoa+withdrawal_from_contract+deposit_from_contract]
(24% fail rate on this branch vs 0% on main).

Fix: when coinbaseEmptyPre would otherwise hold, probe the versionMap
directly for an Estimate floor on Address/Balance/Nonce/CodeHash paths.
If any exists, the read is indeterminate and the SD-emit path is
suppressed; the validator will invalidate the current tx on the prior
write's recorded version mismatch and re-execute against the Done value.

Local repro of the failing fixture: 50/50 pass after fix (was 12/50).

…t Done (#21678)

## Summary

Root-cause fix for the nondeterministic wrong-state-root regression on
this branch, generalizing the Estimate-read handling that `d7f7a40c5d`
patched for one case.

`versionedUpdate` (the `versionedStateReader` used for finalize /
system-tx reconstruction) only consumed a versionMap floor flagged
`Done`, treating an `Estimate` (`MVReadResultDependency`) floor as "not
found" and falling back to the pre-block DB value. Since `221007e6a1`
flushes invalidated txs' writes as `Estimate`, the finalize path
resurrects stale pre-block state whenever a prior in-flight write exists
— committing a wrong write set, producing **nondeterministic wrong state
roots** in EL-requests blocks under parallel execution.

`d7f7a40c5d` fixed one manifestation (the coinbase EIP-161 SD check in
`calcFees`) with a targeted probe; that commit's own message names the
general defect ("versionedStateReader only honours Done floors and
treats MVReadResultDependency … as not found"). This PR fixes it at the
source, so every finalize-path read (storage, all account fields, code)
is covered.

## Commits

1. **finalize reader must consume Estimate cells** — `versionedUpdate`
now consumes a floor that is `Done` *or* `Estimate`. An Estimate floor
holds the same latest in-block write a Done floor does; finalize reads
are re-validated (the tx re-executes) if the writer's value later
changes — the same OCC safety net the rest of the apply loop relies on.
The worker read-path, which aborts on an Estimate read, is unchanged, so
the phantom-write fix this branch targets is preserved.
2. **Revert the `calcFees` coinbase probe** (`d7f7a40c5d`) — now
redundant: `vsReader` returns the coinbase's in-flight value, so
`coinbaseEmptyPre` is computed from the real balance rather than a
spurious nil.

## Verification

The net change is `versionedUpdate` only (the revert cancels
`d7f7a40c5d`), so the branch is code-identical to "this branch before
the coinbase probe, plus the versionedUpdate fix" — the configuration
that was load-tested:

- **eip7685 EL-requests**, 16-worker load, interleaved on one machine:
unfixed branch ~4/30 (blocktest) and 9/25 (engine-x) → **0** with this
fix.
- **Full prague** (2,490 tests) × 4 passes: **0** failures, **0**
regressions vs the serial baseline.
- **Full-prague sensitivity** (5 passes): unfixed 1/5 → **0/5**.
- `execution/stagedsync` + `execution/state` unit tests green (incl.
this branch's phantom-write guard); `go vet` + `make lint` clean.

Single-test runs pass; the bug only surfaces under load (CPU contention
perturbs exec3 scheduling), which is why CI caught it but a one-off run
does not.

Targets `mh/parallel-exec-flush-invalid-as-estimate` so it lands before
#21667 merges.

…omment

Per Copilot review on #21667: cntInvalid is incremented on both
VersionTooEarly (apply loop line 2444) and VersionInvalid (line 2602)
within the same iteration, not only on VersionTooEarly. The
load-bearing property is that the current tx's own verdict is not
included when applyLoopFlushAsComplete is called.

No behavior change.