feat(beacon): builder-specs containers and the fulu blinded block's state root

CLAUDE.md

@@ -669,6 +669,12 @@ existing once per chain.
     validator: helpers that build the active-index `Vec` and then read each
     index back were the largest cost left in the import profile
     (`docs/beacon_stf.md`, "Registry and balances").
+- **`beacon::builder` holds builder-specs containers** (`ValidatorRegistrationV1`,
+  `BuilderBid`, `BlindedBeaconBlock`), not consensus ones: the MEV-Boost relay
+  flow's wire types. `BlindedBeaconBlock`'s root equals the full block's, which
+  is what lets a validator sign a block whose payload it never sees. Electra and
+  fulu shapes only. Tests decode builder-specs' own examples, vendored under
+  `crates/common/types/tests/fixtures/builder_specs/`.
 
 ## Beacon Chain STF (`crates/blockchain/state_transition/src/beacon/`)
 
@@ -872,6 +878,15 @@ transitions are in `ethlambda-types`, per the section above. Nothing above
   that is neither parseable nor listed, so a new fork forces a decision.
 - A fixture case with no `post` state asserts the input must be **rejected**. That
   rule lives in `check_transition`; do not add a runner that ignores it.
+- **`assemble_blinded_block` does not use a blinded STF.** It runs `process_block`
+  on a stand-in payload built from the builder's header, then patches the two
+  post-state fields that depend on the payload itself
+  (`latest_execution_payload_header`, `latest_block_header.body_root`). It
+  also checks the header's `withdrawals_root` itself: the stand-in carries the
+  expected withdrawals, so the STF's own withdrawals check passes trivially. Fulu
+  only, since it is the last fork with blinded blocks. Read the function's doc
+  before touching fulu's `process_block`;
+  `blinded_and_full_blocks_reach_the_same_state_root` fails on any drift.
 
 ## Configuration Files
 

crates/blockchain/state_transition/src/beacon/helpers/fulu.rs

@@ -48,10 +48,9 @@
 //! function mutates state at an epoch boundary, and every other fork's
 //! equivalent epoch-processing step lives in `crate::beacon::stf`, not in a
 //! `helpers::<fork>` module (see [`super::altair`]'s module docs, which make
-//! the same point about `process_attestation`). [`fulu_state`] is kept
-//! alongside [`fulu_state_ref`] for whenever that step is written, the same
-//! way altair keeps a mutable state projection ready for its own
-//! not-yet-written processing steps.
+//! the same point about `process_attestation`). It is
+//! `crate::beacon::stf::epoch::fulu::process_proposer_lookahead`, which writes
+//! the window through [`proposer_lookahead_mut`] rather than [`fulu_state`].
 
 use crate::beacon::constants;
 use crate::beacon::containers::{BeaconState, fulu};
@@ -222,13 +221,13 @@ pub fn initialize_proposer_lookahead(state: &BeaconState) -> Result<Vec<Validato
 
 /// The fulu state, mutably, or an error naming the function that needs one.
 ///
-/// Only [`get_beacon_proposer_index`] needs this: it is the one function in
-/// this module that reads `proposer_lookahead` itself rather than working
-/// through fork-invariant accessors. Kept alongside [`fulu_state_ref`] for
-/// `process_proposer_lookahead`, which will need to write through this same
-/// projection once it is written (see the module docs); nothing in this file
-/// calls it yet.
-#[allow(dead_code)]
+/// The write-side counterpart of [`fulu_state_ref`], for code that writes
+/// fulu-only fields directly, such as `latest_execution_payload_header`, and
+/// must refuse any other fork by name rather than panic. Its callers are
+/// `process_execution_payload` and `assemble_blinded_block`.
+///
+/// `proposer_lookahead` deliberately does not go through here: see
+/// [`proposer_lookahead_mut`].
 pub(crate) fn fulu_state<'a>(
     state: &'a mut BeaconState,
     function: &'static str,