Feat/get supply

[ArthurPaivaT]

No description provided.

[Mctursh]

went deep on this one. the supply tracker is seriously well thought out, the Bootstrapping/Live/GapFilling state machine, the prev-slot supersession filter, the zero-prev startup handling. most of what i'd normally worry about (crash consistency, the gap over-count, the startup race) you've already closed. two things stood out.

the one that matters: commit_block can permanently double-count a redelivered slot. it guards slot <= startup_slot but not slot <= last_applied_slot, and the delta recomputes identically on a reprocess, the prev-balance lookup filters on prev.slot < $slot (strict), so it excludes the slot's own row and finds the same pre-slot baseline. meanwhile indexer.rs calls save_block unconditionally after check_slot_gap, and check_slot_gap's "out of order slot received" branch (slot <= last_slot_received) just logs and returns without stopping the write. so if a slot is redelivered or arrives out of order (grpc reconnect, which is what that branch is there to catch), its delta gets added a second time. the account upserts are idempotent on the (pubkey, slot) PK, but the additive total isn't, so it drifts permanently until a restart re-bootstraps. a last_applied_slot check in commit_block (no-op if slot <= it) makes it idempotent like the account writes already are.

gap_closes never gets pruned. record_gap_closes inserts per closed account during GapFilling, but finish_gap only flips status back to Live, it never clears the map. over a long-lived indexer that recovers from many gaps that grows unbounded. draining it in finish_gap by a safe watermark fixes it.

nothing here is the core accounting, that part's solid. the redelivery idempotency is the one i'd want closed before it serves real numbers.