[EL-ARCH-01] Settle Builder and BN Engine ownership

[krisoshea-eth]

Why

Nico's direct-Engine design leaves a safety-critical deployment choice open. If the Builder and source BN share one EL, both may call forkchoiceUpdated and move the EL's view. Dedicated Builder ELs avoid conflicting writers but add configuration, sync, and resource requirements.

Planning

• Lane: Architecture
• Status: In Progress
• Owner: Kris
• Reviewer: Lodestar maintainer
• Blocks: PAYLOAD-01's final production boundary

Questions

• Is a dedicated Builder EL the supported default?
• Is sharing the source BN's EL supported at all?
• If shared, which component owns head movement and how are conflicting forkchoiceUpdated calls prevented?
• How are safe and finalized hashes sourced and validated?
• Which node identity and custody-group configuration determine the post-Gloas custody_columns passed by the Builder to notify_forkchoice_updated, and can that value be derived safely without another BN field?
• How does an EMPTY or parent-of-head candidate affect the EL until the next BN update?
• What sync, readiness, JWT, and failure isolation checks are required?
• Who owns recovery when Engine forkchoiceUpdated or notifyNewPayload returns INVALID, and how is a shared EL prevented from wedging either the BN or Builder? Track the final disposition of Lodestar #9332.
• Does multi-EL support belong in the first implementation or a later slice?

Evidence required

• A documented ownership invariant.
• One focused shared-EL or dedicated-EL trace.
• Failure and abort behavior.
• Maintainer confirmation.

Done when

PAYLOAD-01 has one explicit supported Engine ownership model with no ambiguous concurrent writer behavior.

Evidence

• Design source: nflaig/lodestar#4
• Engine invalidation watch: ChainSafe/lodestar#9332
• Decision:
• Trace/tests:
• Reviewer:

[linear-code]

LOD-56