test(eip-8297): verify RPC state across cache invalidation

[chugarchugarr]

Description

Advances #3333 by making stale state-RPC reads observable without encoding any client's private cache implementation. This PR does not close the future MPT→PBT transition case because the target branch does not yet implement that activation boundary.

When postVerifications are present, the Engine consumer now uses the fill-time assertions as a live RPC oracle:

• before payload execution, read the exact balance, nonce, code, and storage keys that will be verified, priming any client-side cache;
• execute payloads and advance forkchoice normally;
• read the same fields again and require them to match the fill-time post-state assertions.

The BinaryTree fixture crosses the 128-block horizon from #3333: one slot starts at 1, changes to 2 in block 1, remains untouched through block 128, then changes to 3 in block 129. A stale genesis or pre-flush value fails even when block execution and the committed state root succeed.

Transition boundary

projects/binary-trie currently runs PBT from genesis. The fixture therefore exercises cache churn on the available PBT provider, not an MPT-backed cache surviving an actual flip. When a real activation fixture exists, the same RPC oracle can observe that transition-specific failure without client hooks.

The oracle remains opt-in through the existing --post-verifications fill flag.

Verification

• uv run pytest -q packages/testing/src/execution_testing/cli/pytest_commands/plugins/consume/tests/test_post_state_rpc.py — 4 passed
• uv run fill -q tests/binary_tree/eip8297_partitioned_binary_tree/test_cache_invalidation.py --fork BinaryTree --clean -n 0 — 2 passed
• Ruff check and format check — passed
• git diff --check — passed

Base

projects/binary-trie at 09d2088cf9f338e660cb04f948653baf544b7ba6.

[chugarchugarr]

Closing this contribution to keep my active upstream review surface focused on #3443. This PR received no maintainer review and its fork workflows remained authorization-gated, so I am not asking the project to spend review bandwidth on it.

The branch and diff remain available and can be reopened if a maintainer specifically wants to continue the RPC cache-invalidation oracle.