Gloas (ePBS) support in the ethrex builder's merging role

[0w3n-d]

Status

Merging protocol v1 (crates/tcp-types/src/merging/) carries an
ExecutionPayloadV3 in both directions: relay_to_builder.rs:51 and
builder_to_relay.rs:23. That shape has no room for the EIP-7928 block access
list or the EIP-7843 slot number an Amsterdam block commits to.

The merging role therefore declines Amsterdam bases outright, by name:

// crates/builder/src/engine/session.rs:212
if chain_config.is_amsterdam_activated(v1.timestamp) {
    return Err(MergeError::InvalidBaseBlock(
        "post-Amsterdam blocks are not supported by merging protocol v1".into(),
    ));
}

This is a deliberate stopgap and it fails closed: the role refuses rather than
merging into a block whose hash it cannot reproduce. #561 steps 3 and 4 made the
simulation and building roles Gloas-ready; this issue is the third role, split
out so the Gloas testnet is not blocked on a wire-format change.

Why

Without this, merged block building is unavailable on a Gloas/Amsterdam network.
The relay can still run its own submission path end to end -- submit, simulate,
get_header, get_payload, publish -- with the ethrex builder and simulator, so
this is a missing capability rather than a broken one.

What is already in place

• SignedBidSubmissionGloas carries the list alongside the payload, and
  SignedBidSubmissionGloas::join/split convert between the two shapes
  (Carry the builder's block access list on a Gloas submission #570, Validate a Gloas/Amsterdam block in the simulation role #571).
• The simulation role validates an Amsterdam block, deriving the header's list
  hash and slot number from the submission (Validate a Gloas/Amsterdam block in the simulation role #571).
• The builder produces Amsterdam blocks and knows their list (Build and submit a Gloas/Amsterdam block #575).
• The relay's merged SSZ route already refuses Gloas
  (validation/server.rs::supported_merged_fork), and decode_merge refuses a
  Gloas submission that carries merging data rather than decoding it into the
  Fulu shape and dropping the list (Validate a Gloas/Amsterdam block in the simulation role #571).

Affected surface

File / area	Merging impact
crates/tcp-types/src/merging/relay_to_builder.rs	the base block sent for merging needs its list and slot number
crates/tcp-types/src/merging/builder_to_relay.rs	the merged block returned needs the same
crates/builder/src/engine/session.rs	drop the Amsterdam rejection; recompute the list for the merged block
crates/relay/src/block_merging/tile.rs	thread the list through the merge request and response
crates/relay/src/simulator/client.rs	ssz_merged_request_builder takes no fork and so has no gate; it needs one
crates/builder/src/validation/server.rs	supported_merged_fork can accept Gloas once the above lands
crates/common/src/decoder.rs	decode_merge's Gloas refusal can be lifted, with a Gloas+merging wire shape behind it

Open questions

• Whether to version the merging protocol (v2) or extend v1 with optional
  fields. A v2 forces a coordinated relay/builder deploy; optional fields risk a
  silently-dropped list, which is the failure this issue exists to avoid.
• The merged block's list must be recomputed after the distribution transaction
  is appended, not carried over from the base. Worth confirming ethrex's
  building primitives expose it at that point -- PayloadBuildContext does for
  the building role, so most likely yes.
• Whether the merged block's slot_number should come from the base block's
  header or the relay's own view of the slot. They should agree; a check is
  cheaper than an assumption.

Steps (each becomes one PR)

• Step 1: decide and document the wire-format change (v2 versus optional
  fields on v1), with the deploy-ordering consequence stated (tests: none;
  this step is a decision) (PR: )
• Step 2: carry the block access list and slot number over the merging
  protocol in both directions (tests: the shape round-trips; a pre-Amsterdam
  base is byte-identical to today) (PR: )
• Step 3: merge an Amsterdam base block -- drop the rejection in
  session.rs, recompute the list after the distribution transaction
  (tests: a Gloas base merges; the merged block's list matches what
  execution produces; the base's list is not reused) (PR: )
• Step 4: accept Gloas on the merged validation route and gate
  ssz_merged_request_builder by fork (tests: a merged Gloas request
  validates; a fork with no shape is still refused) (PR: )