perf(chain): add secondary indexes to ProposalMap, eliminate O(n) linear scans

[simonzg]

Why

ProposalMap stores in-flight HotStuff consensus proposals in a single map[Bytes32]*DraftBlock keyed by block ID. Three query methods perform full O(n) linear scans of the entire map on every call:

Method	Called from	Frequency	Old complexity
GetOneByEscortQC	every incoming vote	per vote	O(n)
GetDraftByNum	block seeker, sync	per query	O(n)
PruneUpTo	epoch commit	per epoch	O(n)

GetOneByEscortQC is the most critical: it runs on every vote received during consensus to match the vote's QC back to a known in-flight proposal. With N proposals in-flight (can be dozens during busy view changes), every single vote pays O(N) scan cost — a direct tax on consensus throughput.

What Changed

Two secondary indexes are maintained alongside the primary proposals map:

byNum         map[uint32][]*DraftBlock  // block number → list of drafts at that height
byHeightRound map[uint64]*DraftBlock    // height<<32|round → draft (unique per QC)

GetOneByEscortQC: O(n) full scan → O(1) lookup in byHeightRound
GetDraftByNum: O(n) full scan → O(1) lookup in byNum
PruneUpTo: O(n) scan+delete → iterates only the relevant height buckets in byNum

All three indexes are kept in sync in Add, PruneUpTo, and CleanAll. No external API changes.

Expected Impact

• Per-vote consensus processing cost drops from O(proposals) to O(1) for the proposal lookup step.
• Epoch cleanup (PruneUpTo) no longer scans every in-flight proposal.
• Directly reduces consensus round latency, especially under view changes where many proposals accumulate.