S2 (validation_error wire shape): PayloadStatus.validation_error per
spec is Optional[String] = List[List[byte, 1024], 1]. PR encoded it as
List[byte, 1024] directly, missing the outer one-element-list layer.
Non-empty errors emitted 4 bytes less than spec. Wrap the bytes in a
new SszValidationError container and expose it via [SszList(1)].

S5 (bodies fork-range filtering): per spec, /engine/v2/{fork}/bodies/...
responses MUST mark entries available=false when the block timestamp
falls outside the URL fork's range. Apply the filter at the SSZ-REST
boundary (the underlying engine handler stays unscoped because it's
shared with JSON-RPC). New helper BodiesForkFilter resolves each entry's
engine-API URL segment via SszRestPaths.GetEngineApiUrlSegment and
zeroes out non-matching entries. By-hash uses the requested hashes for
lookup; by-range uses start+index. IBlockFinder bridged into the SSZ
DI container. Regression test
GetPayloadBodiesByHash_marks_out_of_fork_blocks_unavailable verifies a
Cancun-timestamped block at /shanghai/bodies/hash decodes as
available=false (and the test fails on the unfiltered handler).

S8 (payload.max_bytes): drop from 128 MiB to 64 MiB to match the
spec capabilities-response example. The previous inline comment
claimed alignment with a non-existent MAX_REQUEST_BODY_SIZE spec
constant; replace it with a reference to the actual spec text.

S1 (target_gas_limit) and S3 (BYTES_PER_CELL spec ambiguity) skipped
per author preference: target_gas_limit will land separately when the
block-builder side wires through, and BYTES_PER_CELL = 2048 stays
because it's the only value that interops with c-kzg. Both raised on
the upstream spec PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…_BYTES

execution-apis NethermindEth#793 defines MAX_BAL_BYTES = MAX_BYTES_PER_TX = 2^30 and uses
the same ByteList[MAX_BAL_BYTES] type on both block_access_list fields of
ExecutionPayloadAmsterdam and ExecutionPayloadBodyAmsterdam. The PR had:

  SszExecutionPayloadV4.BlockAccessList:  [SszList(0x0100_0000)]  (16 MiB)
  ExecutionPayloadBodyV2Wire.BlockAccessList: [SszList(0x4000_0000)]  (1 GiB)

Internally inconsistent, and the 16 MiB cap on the payload side would
reject spec-conformant CL submissions with a larger BAL even though the
bodies side accepts them.

Align SszExecutionPayloadV4 to MAX_BAL_BYTES = 2^30.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CI red on Ethereum.Blockchain.Pyspec.Test [Sequential] — every Amsterdam
fork test fails with "Unable to determine finalized state root at block 0".
StatelessExecutor.InputDecoder calls NewPayloadRequest.Merkleize on the
SSZ-encoded stateless input, and that root is used to look up the
finalized state. The merkle-tree depth for variable lists is fixed by the
[SszList(N)] limit (depth = ceil(log2(N/32))), so changing the BAL limit
from 0x0100_0000 → 0x4000_0000 changes the V4 payload's merkle root and
breaks the lookup against fixtures generated against the old limit.

The execution-apis NethermindEth#793 sketch says MAX_BAL_BYTES = MAX_BYTES_PER_TX
(2^30), but the pyspec test fixtures (and Nethermind's stateless executor
input format that consumes them) were generated against the 16 MiB value.
Keep 0x0100_0000 here until the upstream spec value is settled and the
fixtures align; the divergence is already flagged on the spec PR
(execution-apis#793#issuecomment-4695124899 / -4695633112). Re-fix later
once spec + fixtures agree.

ExecutionPayloadBodyV2Wire.BlockAccessList stays at 0x4000_0000 — bodies
aren't merkleized by the stateless executor.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>