feat(prune): add a CL-aligned history retention profile

[lean-apple]

Overview

The --full profile currently retains all post-Merge block bodies but only the last 10,064 receipts. There is no profile matching the consensus-layer block-serving window.

The merged EIPs #12257 updates EIP-4444 to align execution history expiry with the 33,024-epoch CL block-serving window:

33,024 epochs * 32 slots = 1,056,768 blocks

Using a block distance is conservative because missed slots cause over-retention, never under-retention.

CLI design

Option A: add --cl-window (preferred)

Add a standalone profile while keeping --full unchanged:

reth node --cl-window
reth download --cl-window

This is explicit and preserves the behavior and storage expectations of existing --full users.

Option B: update --full

Keep the existing commands:

reth node --full
reth download --full

Change --full to retain receipts and transaction lookup data for 1,056,768 blocks while continuing to retain all post-Merge block bodies. This avoids adding another profile and preserves the current body coverage, but changes the receipt retention and storage requirements for every --full user.

Profile

The profile should:

• retain bodies, receipts, and transaction lookup data for at least 1,056,768 blocks;
• reuse the existing --full account history, storage history, and sender recovery settings;
• preserve headers locally while applying the CL boundary to P2P history advertisement and serving;
• use the same profile definition for node pruning, sync, and modular snapshot selection;
• follow the same conflict rules as the other named pruning profiles.

Snapshot chunk boundaries may cause slight over-retention, but downloads must never cover less than the configured window.

Existing datadirs

Changing the retention target does not restore previously pruned data. An existing --full datadir may only contain receipts for the latest 10,064 blocks, so either CLI approach leaves an older missing receipt range.

The node should detect actual contiguous body and receipt coverage, warn when the configured window is incomplete, and advertise actual availability rather than the configured target.

A matching snapshot provides the immediate recovery path through a replacement datadir. The command depends on the selected CLI approach:

reth download --cl-window --datadir /path/to/cl-window-datadir
reth download --full --datadir /path/to/cl-window-datadir

The current modular downloader is not an in-place repair tool because it also selects required state and headers and updates configuration and checkpoints. import-era --with-receipts cannot repair this case either because it appends from the receipt tip, while previously pruned receipts form a missing prefix.

In-place recovery is not required here. We should decide whether snapshot replacement is sufficient or whether range-based backfill needs a separate follow-up. A follow-up could reuse modular snapshot range downloads and ERA1/ERE receipt validation.

Acceptance criteria

• One CLI approach is selected and applied consistently to reth node and reth download: add --cl-window, or update --full to provide the CL receipt window while retaining all post-Merge bodies.
• The selected approach uses a shared CL retention distance of 33_024 * 32 = 1_056_768 blocks.
• The profile retains bodies, receipts, and transaction lookup data for at least the configured window while preserving headers and reusing the existing --full account history, storage history, and sender recovery settings.
• Sync, pruning, P2P history advertisement and serving, and modular snapshot selection apply the profile consistently.
• Existing datadirs with incomplete body or receipt coverage are detected, produce a clear warning, and advertise only the history that is actually available.
• Snapshot chunk boundaries may over-retain but never leave the downloaded history shorter than the configured window.
• CLI, profile, pruning, and snapshot-selection behavior is covered by tests.
• The Storage V2 footprint is measured at a stated mainnet block, and the pruning, snapshot, storage, system requirements, and generated CLI documentation are updated accordingly.
• The issue or implementation records whether replacement snapshots are sufficient for existing datadirs or whether range-based in-place backfill will be tracked in a separate follow-up.