Harden BFT replay and decided-block validation failure modes

[Zk-nd3r]

Issue Draft: Harden BFT replay and decided-block validation failure modes

Summary

Two BFT block handling paths should be hardened:

1. Startup replay reads the full pos.chain, parses all BFT blocks/RoundData into memory, and retains internal.bft_blocks without pruning.
2. Decided-block validation happens before the gap-fill insertion loop, so a bad huge-height decided block should not grow bft_blocks; however, the caller uses assert/panic behavior, so a bad decided block can abort the process rather than being handled as a graceful reject.

Why It Matters

The live bad-height memory balloon theory does not appear correct for the decided-block path because validation gates before insertion. But the panic failure mode is still crash-relevant, and the full replay retention path is a plausible memory-pressure risk on long-running or large-history nodes.

Suggested Direction

• Stream startup replay instead of read_to_end where practical.
• Add explicit replay bounds and validation around expected BFT height/header counts.
• Replace assertion-based decided-block failure with graceful rejection/logging where safe.
• Prune or bound retained BFT block history if the protocol permits.

Scope

This is an issue/request for hardening, not a tested patch proposal.