Lc historical backfill

[AbolareRoheemah]

Issue Addressed

Part of the EPF Cohort 7 "Decentralized CL Checkpoint Sync" project (Phase 1a: local historical light client data collection). Related proposal: LightHouse Decentralized Checkpoint Sync Project Proposal.

Proposed Changes

• Adds an opt-in, off-by-default background task that backfills historical light client data.
• Walks finalized sync committee periods forward, from the node's earliest available state (store.get_historic_state_limits().1) to the most recently finalized period at task start.
• For each period, feeds every block through the existing recompute_and_cache_light_client_updates path.
• Resumable via a new LightClientEpochBackfillProgress singleton, stored under the existing DBColumn::BeaconMeta.
• Detects blocks the canonical chain expects but that are missing from the block store, logs a warning, and stops the current period without advancing the watermark, so it's retried on a later run instead of silently skipped.
• The task re-runs on an interval, so it both retries after a gap and picks up periods that finalize after the task starts.

Additional Info

• Scoped to Phase 1a (local collection) only. The P2P serving endpoint (Phase 1b) is a separate follow-up PR.
• Coverage depends on get_historic_state_limits(), a non-archive, checkpoint-synced node will only backfill from its own checkpoint forward, not from genesis.
• No priority-aware yield mechanism exists yet for pausing between periods to protect validator duties. Open item, not addressed in this PR.
• Marking as draft. Feedback is much welcome before this goes further.