getFeeStats: rebuild fee windows on restart

[karthikiyer56]

What

• v2's fee windows are in-memory only, so a restart replays the last max(classic window, soroban window) ledgers (≤1000) to refill them before live ingestion resumes.
• Reframed after SDK: one TxProcessing walk per ledger — ExtractLedgerTxParts + per-product functions (supersedes the extractor bundles) #912 / v2 ingestion: one walk per ledger — migrate backfill + streaming to parts/products, and feed the getFeeStats windows #881: the replay is the fees-only consumer of the shared walk — ExtractLedgerTxParts → FeesFromTxParts, nothing else computed. Exactly the third composition the SDK reshape was built for.

How — raw bytes through the view path (changed from the earlier plan)

• The earlier plan was "StreamLedgerRange with v1's IngestFees as the store.StreamLedgerFn callback". It is dead. The ELI5 of why — do not resurrect it by routing the replay through store.LedgerReader, even though that looks like the blessed seam:
  • The store interfaces exist for one audience: the shared JSON-RPC handlers (Wire the v2 stores into the API handlers and support both v1 and v2 #772). Their currency is parsed xdr.LedgerCloseMeta because handlers work on parsed data (store.StreamLedgerFn is func(xdr.LedgerCloseMeta) error). The replay is not a handler — it's ingestion refilling its own in-memory cache. Wrong seam, wrong audience.
  • Going through that seam forces a full LCM decode per replayed ledger — the only full decode anywhere on the v2 path, paid up to 1,000 times on every restart, just to walk data the view extractor reads for free off raw bytes.
  • v1's feewindow.IngestFees lives under internal/rpcv1/, and v2 code may not import rpcv1/ (the depguard rules from Reorganize stellar-rpc into shared/rpcv1/rpcv2 trees and build both binaries #876). Reusing v1's ingestion here was never actually possible after the reorg.
  • Bonus from the bypass: this ticket sheds its LedgerReader + LedgerReaderTx adapter #885 dependency. Reading the router's ReadView directly means the replay can be built as soon as v2 ingestion: one walk per ledger — migrate backfill + streaming to parts/products, and feed the getFeeStats windows #881 lands, without waiting for the LedgerReader adapter.
• New mechanism — the same code path as live ingestion's fee product:

# pseudocode; real types are query.ReadView / xdr.LedgerCloseMetaView
view = registry.NewReadView()          # frozen range + handle set; defer view.Release()
latest = lastCommittedLedger           # the hot loop resumes at latest + 1
start  = max(latest - window + 1, view.OldestLedger())
if start > latest:
    return                             # fresh start / short history: no-op, not an error

for entry in view.ScanLedgers(start, latest):
    lcm   = LedgerCloseMetaView(entry.Bytes)
    parts = ingest.ExtractLedgerTxParts(lcm)   # the one walk
    fees  = ingest.FeesFromTxParts(parts)      # fees only; events never computed
    # seq + close time read off the view header; append to BOTH windows,
    # each trimming to its own retention
    windows.AppendLedgerFees(seq, closeTime, fees)

• entry.Bytes is borrowed (it aliases the reader's scratch buffer, overwritten on the next step) — fine here: fees are folded within the loop body and only plain uint64 slices are retained.
• The replay range spanning a chunk boundary is the common case, not an edge case (any restart within the first window ledgers of a chunk). ScanLedgers does the split and per-chunk clip; ≤1000 ledgers means at most 2 chunks, so routing failures surface before any ledger is emitted.

Ordering — the double-count hazard

• The replay covers [start, lastCommitted]; the hot loop starts feeding the same windows at lastCommitted + 1.
• The replay must complete before the hot loop starts, or the boundary ledger is counted twice.
• The windows live at daemon level and are injected into both the replay and HotService (see v2 ingestion: one walk per ledger — migrate backfill + streaming to parts/products, and feed the getFeeStats windows #881 work item 3).

Scope notes (carried over, still true)

• Clamp to what exists: on a fresh start OldestLedger() can exceed latest by one, so a short history must be a no-op, not an error.
• No config-time window-vs-retention guard needed (v1 has one): windows are capped at 1,000 ledgers (limits.MaxFeeStatsRetentionWindow) and v2's smallest retention is one chunk = 10,000 ledgers, so the guard can never fire.

Dependency change

• No longer depends on LedgerReader + LedgerReaderTx adapter #885. The replay reads the query router's ReadView directly over raw bytes — it never touches store.LedgerReader. (The store seam exists for handlers; the replay is ingestion.)
• Depends on: v2 ingestion: one walk per ledger — migrate backfill + streaming to parts/products, and feed the getFeeStats windows #881 (shared windows + FeesFromTxParts wired), Implement concurrent query serving: ingestion changes and the query router #865/Query routing: serving foundation (write + read side) #894 (query router — done).

Sizing

• ~80–120 lines in 1 file, ~6 tests (unchanged estimate).