fix(explorer): advance address-history cursor by hashes consumed

[Tleaoo]

What happened

I was paging through the activity feed for a busy address and noticed the list
just… stopped advancing. Same rows kept coming back, and for one address the
"load more" button spun forever without ever moving past a certain point.

After digging in, here's what's going on. The address endpoint assembles a page
of hashes from a few different places — the txs table, but also transfer rows
and emitted-log rows, plus the contract-creation tx. We then call
fetchTxDataByHashes to hydrate them, and that helper only reads the txs
table. So any hash that came from the transfer/log side has no matching tx row
and gets quietly filtered out.

That filtering is fine on its own — the trouble is what we did next. The
pagination cursor was computed from the hydrated count:

const nextOffset = offset + transactions.length

If a 20-hash page hydrates to only 15 rows, the cursor moves forward by 15, not
20. Next request starts at offset 15 and happily re-selects the five hashes we
already skipped — duplicates, stalled progress. And in the worst case (a whole
page with no tx data) transactions.length is 0 while hasMore is still true,
so the client loops on the same offset forever.