Backfill sync and block/blobs retention

### Problem description

Noticed we don't have an open issue for this. Currently, Lodestar does not backfill and serve blocks/blobs as a typical good peer would for network health.

This feature is important because:
- It's technically ["out-of-spec" behaviour](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#beaconblocksbyrange-v1) / reduces pool of nodes that can sync
- We could be less useful if a large portion of the network goes down
- It's important for increasing our market share of the network
- In PeerDAS, it will be important as people will query data that is based on our custody group counts
- Reduce storage requirements, better UX

### Solution description

We need to implement:
- Backfill sync
- Serve blocks up to `MIN_EPOCHS_FOR_BLOCK_REQUESTS` (and blobs) after checkpoint syncing the node to last finalized

We may want to look into Lighthouse's model where they only allow a single checkpoint sync per DB to prevent "holes". One pointer that goes back from checkpoint sync to genesis.

### Additional context

_No response_

Start by tracing the existing checkpoint syncing flow and the block/blob serving paths, then compare their behavior with the stated backfill requirements. Verify how MIN_EPOCHS_FOR_BLOCK_REQUESTS is applied and how checkpoint sync could avoid database holes. Done means implementing backfill sync and serving blocks and blobs through the required retention window after syncing to the last finalized checkpoint.

Written by the indexing model from the issue text.