perf: read block times from storage instead of the indexer

[moul]

Closes #34.

After the earlier fixes, list endpoints were still slow against the live deployment:

/api/txs?limit=50&network=topaz    6.3s
/api/txs?limit=100&network=topaz   4.3s

Measuring rather than guessing found it was not our box — mygnoscan had used 4.3s of CPU total since restart, and the local indexer answered in 1ms. It was upstream: the public topaz indexer answers in ~0.25s per request, and stampBlockTimes asks it once per distinct block. A page spanning 50 blocks therefore spends well over a second on timestamps alone, and that is the whole difference.

The syncer has been storing block_time on every transaction it writes all along, and after #55 and #59 that coverage extends to historical rows too. So the indexer never needed to be asked for most of them.

stampBlockTimes now reads from transactions first and only queries the indexer for heights it does not already know — typically the handful of blocks newer than the last sync pass. For a fully-synced network that is zero indexer round trips where there used to be one per block.

Being a method on API rather than a free function is what gives it database access; the network is passed explicitly so the lookup stays network-scoped.

Tests

BlockTimesForHeights returns stored times, scopes to the network, and — the important part — omits heights with an empty or missing time rather than returning a blank string. That is what lets the caller ask the indexer for exactly the gap instead of assuming it has everything.

Note

Absolute numbers on the deployment are noisy at the moment: the box is running a validator at ~100% CPU, and the public topaz indexers own latency varies by 5x between samples. The structural change — one query instead of N network round trips — is what matters here, and it is what remained of #34.