Retention-finality pruning: full node in single-digit GB (not 76)

[Reiers]

Part of #87 (Full Node epic). Stage A — the <100 GB tweak.

Lotus discard-splitstore keeps ~4 finalities hot (~tens of GB). Lantern can go lower because it doesn't re-execute and F3 lets it drop below finality:

• Always keep: all block headers (~380 MB), F3 certs, DRAND, actor code.
• Keep recent: state + messages + receipts for the last N finalities (tunable "retention-finalities" knob; default low = a few GB).
• Drop older: CID-verified cache makes any dropped block safely re-fetchable on demand.

Target: single-digit-to-low-double-digit GB steady state instead of 76 GB. Tunable up for archive roles. This is the config knob answering "can we tweak the 100 GB hotstore?" — yes.

[Reiers]

Design refinement:

• Retention depth should be driven by the FRC-0089 EC finality calculator (Lift FRC-0089 EC finality calculator (lotus chain/ecfinality): observed-data finality without F3 #96), not a static epoch count. Prune below min(ec-finalized, f3-finalized) minus a configured safety margin of finalities. On a healthy chain that computes to ~30 epochs, not 900 — deeper cuts when safe, automatic caution when block production degrades.
• Storage mechanics: this rides the existing Badger persistent cache (pins + LRU already exist). Add epoch-tagged keys so pruning is a range drop, not a scan.
• Pinned always-set (never pruned): all headers, F3 certs, DRAND entries, actor code, node-profile state.
• Everything pruned remains safely re-fetchable (CID-verified) via bitswap/gateway — pruning is a cache policy, not data loss.

Depends on #96; pairs with #91 (the two halves of the Full-tier footprint design).