fix: preserve anchor FULL variant seeding in ProtoArray.initialize

Per bot review feedback on PR: removing the `onExecutionPayload(anchor, ...)`
call alongside the PTC vote override broke block production after restart from
a post-Gloas anchor. `shouldExtendPayload(anchorRoot)` (used in #9209) short-
circuits to false via `!hasPayload()`, so `produceBlockBody`/`prepareNextSlot`
pick `latestExecutionPayloadBid.parentBlockHash` instead of `.blockHash`,
producing bids that fail `processExecutionPayloadBid`'s parent-hash check.

Upstream consensus-specs `c7a0a8527` removes only the PTC vote seeding
(`payload_timeliness_vote={}`, `payload_data_availability_vote={}`) — it does
not remove the FULL-payload semantics of the anchor. The anchor state's
`latestBlockHash` is the executed payload hash, so `onExecutionPayload(anchor)`
still matches the spec's intent of `payload_states = {anchor_root: ...}`.

Keep the PTC vote override removal (the actual subject of this PR); restore
the FULL-variant seeding with a focused comment.

🤖 Generated with AI assistance

Author: lodekeeper

packages/fork-choice/src/protoArray/protoArray.ts

@@ -109,6 +109,21 @@ export class ProtoArray {
       null
     );
 
+    // Gloas: seed the anchor's FULL variant so `shouldExtendPayload(anchor)` is true
+    // for block production; otherwise bids after restart use `bid.parentBlockHash`
+    // and fail `processExecutionPayloadBid`'s parent-hash check.
+    if (isGloasBlock(block as ProtoBlock) && block.executionPayloadBlockHash !== null) {
+      protoArray.onExecutionPayload(
+        block.blockRoot,
+        currentSlot,
+        block.executionPayloadBlockHash,
+        (block as {executionPayloadNumber?: number}).executionPayloadNumber ?? 0,
+        block.stateRoot,
+        null,
+        ExecutionStatus.Valid
+      );
+    }
+
     return protoArray;
   }