[xenoliss]

Why

Backports paradigmxyz#28148 (upstream commit 3c8b4e8) onto releases/v2.8.1.

When a block destroys an account (for example an EIP-161 cleanup) and recreates it in the same block, the bundle account ends with status DestroyedChanged: it was destroyed, but it has post-block info and storage. ExecutionCache::insert_state treated every destroyed account the same way. It removed the account from the account cache and skipped the rest, so the storage written by the recreation never reached the storage cache. If a slot of that account had been cached during prewarming (for example as zero), the stale value stayed in the cache. The next block then executed against the wrong value and the node rejected a valid block.

What

Cherry-picked with -x, upstream authorship kept. The upstream change only removes a destroyed account from the cache when it has no post-block info (account.info.is_none()). Otherwise the account falls through to the normal path, which writes its info and storage. The production change applied cleanly and is identical to upstream.

The only adaptation is in the test module's imports, resolved inside the cherry-pick commit. v2.8.1 imports the bundle types from reth_revm::db and AccountInfo from revm::state, not from upstream main's reth_trie_common::bundle_state and evm2::evm. So the new test's StorageSlot is imported as reth_revm::db::states::StorageSlot. The upstream test body is unchanged.

Testing

• cargo +1.96.0 test -p reth-execution-cache --lib: 21 passed, including the new test_insert_state_recreated_account_updates_cached_storage.
• With the production change reverted, the new test fails (left: Some(0), right: Some(7)). It catches the stale cached slot.
• cargo +1.96.0 clippy -p reth-execution-cache --lib --tests --all-features --locked -- -D warnings: clean.
• cargo +nightly fmt --check: clean.

Closes CHAIN-6833