cl: enable Gloas FULL-parent payload preparation

Follow-up to #23436.

## Problem

Direct payload preparation can start a builder only when the requested parent is already the execution layer's fork-choice head. In the normal Gloas FULL path, the execution payload envelope is validated with `NewPayload`, but that does not move the execution fork-choice head from the bid's EMPTY parent to the delivered payload hash. The ordinary proposal-time fork-choice update performs that move too late to provide warmup.

#23436 therefore limits Gloas preparation to pre-fork and genuine EMPTY paths. It keeps production live by using the normal fork-choice update and by falling back to the consensus-valid EMPTY parent when the materialized proposal head cannot be matched to a resolved payload status.

## Desired result

Allow a validator to prime a Gloas FULL-parent local build before its proposal slot, without sending a speculative fork-choice update from the preparation loop.

The preferred design should advance the execution head only from a canonical Gloas fork-choice decision, after the FULL payload has been verified. If that ownership does not fit the existing stage flow, define another safe builder-start contract that preserves the same canonical-head and liveness guarantees.

## Requirements

- Bind the FULL decision, execution payload envelope, beacon root, and execution head to one canonical fork-choice view.
- Keep block import, envelope validation, fork choice, and proposal production live under a slow or busy execution layer.
- Do not let speculative preparation own or delay the canonical fork-choice update.
- Preserve normal production as the authoritative fallback when preparation is absent, late, or mismatched.
- Handle FULL, EMPTY, and FULL-to-EMPTY decisions explicitly.
- Add an end-to-end test with the real execution module that follows the live sequence: block import, envelope validation, canonical head update, preparation, production fork-choice update, and collection of the same payload ID.
- Cover head changes and payload-status invalidation during the preparation window.

## Specification context

- [Gloas fork choice](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/fork-choice.md)
- [Gloas validator block proposal](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/validator.md)

## Done when

- A steady-state Gloas FULL-parent proposal receives measurable builder warmup before its slot.
- The preparation path does not issue a speculative fork-choice update.
- The execution head and payload attributes used by preparation match normal production.
- Failure or contention in preparation cannot cause a missed proposal or delay canonical block processing.