Sync wedges in UpdatingPivot after early restart with no peers — forkchoice hashes not persisted on the unresolvable-header path

[stdevMac]

Summary

A node restarted before its first sync pivot is resolved can get permanently stuck in the UpdatingPivot stage. On the unresolvable-header path the forkchoice (finalized/head) hashes delivered by engine_forkchoiceUpdated are never persisted, so after a restart the re-sent FCU never feeds StartingSyncPivotUpdater and the pivot never resolves. Sync wedges silently — no crash, no error log that points at the cause.

Setup / when it happens

• master (found via the post-merge smoke fuzz tests that kill/restart the EL early in sync).
• Most reproducible when the node restarts with zero peers before the first pivot update.

Root cause

BeaconSync.GetFinalizedHash has no fallback to a persisted BlockTree.FinalizedHash. The finalized/head hashes from ForkchoiceUpdated live only in memory while the first pivot is being resolved. If the process restarts before StartingSyncPivotUpdater completes the first pivot:

1. The in-memory forkchoice state is lost.
2. On restart the CL re-sends FCU, but the unresolvable-header path does not persist those hashes.
3. StartingSyncPivotUpdater never receives a usable finalized hash, so the pivot is never set and the node sits in UpdatingPivot indefinitely.

Fix (PR linked below)

• Persist forkchoice hashes on the unresolvable-header path so they survive a restart and StartingSyncPivotUpdater can resume (ForkchoiceUpdatedHandler, BeaconSync, StartingSyncPivotUpdater).
• Distinguish "no FCU data yet" from "unresolvable finalized" in the pivot-wait log so the wedge is diagnosable.
• Regression coverage: StartingSyncPivotUpdaterTests, EngineModuleTests.Synchronization.

Related (NOT duplicates)

• Chiado node after several early restarts crashed Old Headers with orphaned block exception #8029 — orphaned-block crash in HeadersSyncFeed in the same headers/pivot subsystem, but a crash path, not this silent forkchoice-hash non-persistence wedge.
• Node stuck with sync when PivotUpdator changed block for second time based on FCU #6304 (closed) — UpdatingPivot stuck due to premature Beacon pivot vs general pivot; different root cause (addressed by Block beacon header sync until global pivot is updated #7614).
• Remove timeout from AutoPivot to avoid situation with missing Headers #5986 — AutoPivot timeout; different mechanism.

Found during 1.38 smoke-test triage. Must not be allowlisted in the smoke harness — it would hide a real sync-recovery wedge.

[marcindsobczak]

Seems like we had this issue in the past:
#6304

Solved it:
#7614

And looks like now we have regression after:
#11022

As a first fix attempt, I would try to revert the commit from above - this kind of regression is not surprising:
#11022 (comment)
#11022 (comment)