fix(l1): honor targetGasLimit in testing_buildBlockV1

[MysticRyuujin]

testing_buildBlockV1 read slotNumber from the raw payload attributes but dropped targetGasLimit. It always passed the node's static gas ceiling to BuildPayloadArgs, so post-Amsterdam attributes could not steer the built block's gas limit. The engine path already uses the attribute: build_payload_v4 sets gas_ceil from attributes.target_gas_limit.

This change reads targetGasLimit from the attributes object, the same way the handler reads slotNumber, and uses it as the gas ceiling when present. When the field is absent, the handler keeps the node's static ceiling, so pre-Amsterdam calls do not change.

Adds a parse test and a handler test. The handler test passes a targetGasLimit equal to the parent's gas limit and asserts the built block keeps that gas limit; it fails without the fix.

go-ethereum had the same bug and fixed it in ethereum/go-ethereum#35501. See also ethereum/execution-apis#857 and ethereum/execution-apis#862.

[greptile-apps]

Greptile Summary

The PR teaches testing_buildBlockV1 to parse targetGasLimit and use it as the payload builder's gas ceiling, while retaining the configured ceiling when the attribute is absent.

• Generalizes hexadecimal quantity decoding to produce field-specific errors.
• Adds parsing and block-building tests for targetGasLimit.
• Leaves targetGasLimit active for pre-Amsterdam timestamps, unlike slotNumber and the Engine V4 path.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking fork-gating inconsistency for pre-Amsterdam fixture requests.

The intended post-Amsterdam targetGasLimit path is implemented and covered, but a caller can also supply the field before activation and override the configured gas ceiling where the corresponding Engine path would reject it.

Files Needing Attention: crates/networking/rpc/testing.rs

Important Files Changed

Filename	Overview
crates/networking/rpc/testing.rs	Correctly forwards targetGasLimit into payload construction and tests the main path, but does not gate the Amsterdam-specific field by fork activation.

Prompt To Fix All With AI

### Issue 1
crates/networking/rpc/testing.rs:164
**Gate target gas by Amsterdam**

For a pre-Amsterdam timestamp, `target_gas_limit` still replaces `context.gas_ceil`, so fixture generation derives the block gas limit from a fork-inactive attribute even though this handler gates `slotNumber` and the Engine V4 path rejects such attributes.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix(l1): honor targetGasLimit in testing..." | Re-trigger Greptile}