refactor(consensus/proposal): encapsulate ordering rules in store

[RafaelGranza]

Summary (ISSUE)

ProposalStore was leaking coordination rules (ordering, what's safe to write/delete and when) across call sites. This refactor pushes those rules into the type itself so new callers can't violate them.

What changed

• Storage layout: flat sync.Map[Hash]*BR to nested sync.Map[Height]*sync.Map[Hash]*BR.
• Finalized cursor: atomic.Uint64 advanced monotonically via CAS in DeleteUpToHeight.
• Store: no-op if height <= finalized; recheck-then-self-clean after publish to handle races with a concurrent sweep.
• Get: late height <= finalized check before returning, so readers never observe entries past the cursor even during a race.
• IsFinalized(height): utility for callers that want to distinguish cache miss from finalized-height query.
• DeleteUpToHeight: now O(num_heights). Drops outer entries; GC handles the inner sync.Maps.

The public API (Get(hash), Store(hash, br), DeleteUpToHeight(h)) is unchanged for callers; no signature changes leak into the tendermint.Application interface.

Design note

There was a real trade-off in how to balance cost between Get and Delete:

Layout	Get	Delete
Flat sync.Map[Hash]*BR	O(1)	O(N) where N = total entries
Nested sync.Map[Height]*sync.Map[Hash]*BR (this PR)	O(num_heights)	O(num_heights)

Picked the nested layout because num_heights is small in practice (1 to 3 in steady state, up to ~5 with stragglers), so the O(num_heights) Get is sub-100ns and invisible end-to-end (network and VM latency dominate). The benchmarks below confirm the Get hit stays in the tens of nanoseconds.

The flip side is meaningful: Delete cost is decoupled from total entry count. That's where the big speedup comes from.

Benchmark comparison

Apple M-series, go test -bench -benchmem. Spread across 5 live heights to reflect realistic steady-state consensus.

Workload	New (bucketed)	Legacy (flat)	Delta
StoreThenGet (seq)	586ns	558ns	~noise
ParallelGet	24ns	12ns	~2x slower, sub-30ns
ParallelMixed (10% writes)	51ns	31ns	~1.6x slower, sub-100ns
DeleteUpToHeight (16 heights x 64 hashes)	1.6µs	101µs	~62x faster

The benchmark file (proposal_store_bench_test.go) is included as requested for future comparisons.

[codecov]

Codecov Report

❌ Patch coverage is 84.21053% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.34%. Comparing base (e27e9f5) to head (617a7eb).

Files with missing lines	Patch %	Lines
consensus/proposal/proposal_store.go	83.78%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3675      +/-   ##
==========================================
- Coverage   76.38%   76.34%   -0.05%     
==========================================
  Files         396      396              
  Lines       36579    36596      +17     
==========================================
- Hits        27941    27938       -3     
- Misses       6664     6682      +18     
- Partials     1974     1976       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rodrodros]

@RafaelGranza the benchmark only shows performance data, but there is no memory usage benchmark, could you please add them as well

[ongyimeng]

Nice refactor, the abstraction looks cleaner with these rules inside ProposalStore. I also like the atomic cursor + sync.Map approach, the concurrency design is quite elegant.

[rodrodros]

LGTM! Merge at will