perf: compute gas stats from stored transactions

[moul]

Closes #51.

/api/gas took 4.3s to return 6.5 KB, because it downloaded every transaction on the chain from the indexer and aggregated them in Go — the same unbounded pattern fixed in #45 and #48.

It could not be fixed the same way. The page presents all-time totals ("total txs", "gas used", "total fees", success/failed), so bounding the query to a recent window would silently understate every number. Slow and correct beats fast and wrong.

Computing it locally

The transactions table already stores gas_used, gas_wanted, gas_fee and success per network, so the totals are one aggregate. Per-realm gas comes from joining transactions to whichever table recorded the message; top transactions resolve their type and target the same way.

/api/gas?network=topaz: 4.3s → 0.13s, same shape of response.

The part that made this non-trivial

Switching naively would have shipped a correctness regression. The transactions table was added after the event tables, and incremental sync only writes it going forward — so on the live instance it held 37 rows for a network with 2738 transactions. Local aggregation would have reported gas totals ~70x too low while looking perfectly plausible.

Gas figures exist only on the transaction row, so they cannot be reconstructed from what is already stored. backfillTransactions fetches the missing rows back from the indexer: newest first, 100 blocks per sync pass, 10 requests in flight. Measured on real data, 129 → 423 rows in three passes; a full gap of ~2700 closes in about twelve minutes and then costs one cheap query per cycle.

Operators should know: for the first few minutes after upgrading, gas totals for networks with pre-existing history will read low and climb as the backfill runs. Networks synced entirely by a recent build are unaffected.

Sits on top of #55, which repaired block_time the same way.

Tests

• GetGasStats totals, success/fail split, per-realm attribution and top-transaction ordering, plus an assertion that another networks gas does not leak into the totals.
• HeightsMissingTransactions finds events with no transaction row, ignores properly paired ones and other networks, and reports nothing once the gap is filled.