fix: complete payload builder gas overflow error propagation

[crazywriter1]

Summary

Completes the defensive gas accounting started in #42 (reopen of #24). That PR replaced saturating_add with checked_add, but left two .expect("total gas shouldn't overflow") calls that could still panic the payload builder. This change applies the error-handling pattern requested by @atiwari-circle in the #24 review.

Changes

crates/execution-payload/src/payload.rs

1. Pre-execution capacity check — cumulative_gas_used.checked_add(pool_tx.gas_limit()).is_none_or(|total| total > block_gas_limit)
   If addition overflows (not practically reachable — both values are bounded by block_gas_limit), the transaction is treated as not fitting and marked invalid via ExceedsGasLimit, instead of panicking.

2. Post-execution cumulative update — checked_add(gas_used) now returns PayloadBuilderError on overflow instead of .expect(). A silent clamp or panic would let the builder continue past safe accounting; overflow now fails the build cleanly.

Context

• fix: use checked arithmetic for cumulative gas accounting in payload builder #24 — original PR; review noted saturating_add on the cumulative update was wrong
• fix: use checked arithmetic for cumulative gas accounting in payload builder #42 — merged checked_add but retained .expect() at both sites
• Overflow remains theoretically unreachable in production (block_gas_limit ~30M vs u64::MAX), but checked_add with explicit propagation is the semantically correct primitive

Testing

• cargo fmt -p arc-execution-payload -- --check
• cargo clippy -p arc-execution-payload --all-targets -- -D warnings
• cargo test -p arc-execution-payload — 25 passed