chore: fix flaky frag RPC handling in based-op-geth

[pamungkaski]

Problem

• The engine_newFragV0/engine_envV0 RPCs are not idempotent: retries or duplicate deliveries return INVALID and drop the in-progress unsealed block.
• Stale or replaced env payloads cannot supersede an in-progress block, leading to desync when the beacon/client resends a newer env.
• Duplicate frags for the same sequence are treated as errors instead of no-ops, so transport retries can cause us to discard the block.
• Sealing is fragile: missing pre-sealed blocks and duplicate seals bubble errors, and we were still missing validation for blob gas used and withdrawals roots.
• Leftover TODOs around frag/env validation were unaddressed, leaving gaps in sequence checks and dedupe logic.

Impact

• Builder/relay retries over flaky networks can cause INVALID responses and force the caller to reopen blocks, making frag ingestion flaky.
• We may discard valid work (by resetting the unsealed block) even though the peer only retried the same data, leading to orphaned payloads and wasted sealing cycles.
• Seals can fail late due to missing validation coverage (blob gas/withdrawals), reducing observability into bad inputs.

Plan to fix

1. Make NewFragV0 idempotent: accept duplicates when payloads match, drop stale block numbers, and only reject unexpected sequence gaps while returning VALID on safe retries.
2. Make EnvV0 idempotent and replaceable: drop stale envs, treat identical envs as no-ops, and allow replacing an in-progress unsealed block with a newer env.
3. Harden sealing: treat missing pre-sealed blocks and duplicate seals as benign INVALID/VALID responses, and add explicit checks for blob gas used and withdrawals root.
4. Add tests covering duplicate env/frags and duplicate seal flows to prevent future flakiness.