Count epoch block txs by id and clamp block-range sampling

[ArturWieczorek]

Closes #2170.

Two cardano-db-tool validate checks were quietly wrong. Both were only visible once the error-isolation change in #2163 stops validate aborting on the first failure, so they were surfaced during review of that work.

The epoch block-tx check counted transactions with queryBlockTxCount, which keys on block.id, but fed it the block_no returned by queryEpochBlockNumbers. block_no and the surrogate block.id diverge on any real chain - an EBB has a null block_no and a positive id, and the id is just a sequence - so the check looked up the wrong block and reported false tx-count mismatches on mainnet, preprod, and preview. queryEpochBlockNumbers now returns the block id alongside block_no, and the check counts by the id while still printing block_no in the message. The shared queryBlockTxCount was always correct and is used correctly by sync's genesis validation; only this validator misused it.

The block-property checks (contiguous block numbers, ordered timestamps) picked a random start with blkCount - 100000 in Word64, which underflows to an enormous value on any database with fewer than 100000 blocks - local/private clusters and DBs early in their first sync. That produced absurd ranges like Block numbers [12258611005600085411 .. ...] (and a false "ok" on the empty result). A small sampleWindow helper now clamps the window to the available block count, so the range is always valid. This never affected preprod, preview, or mainnet, which are all far past 100000 blocks.

The first commit adds a failing regression test in the cardano-db IO suite that models the id/block_no divergence (a block with a null block_no and a positive id, one transaction) and asserts the returned identifier counts the right block; the second commit is the fix. Bug 2 was verified end to end against a small local db-sync database, where the range now reads Block numbers [0 .. 16608] instead of the underflowed value.

Marked WIP/draft. Note this overlaps Validate/BlockTxs.hs with #2163 (which changes how the same check reports failures), so expect a small merge conflict there - the two changes are complementary: this PR fixes the check's logic, #2163 fixes its reporting and exit code. Bug 1 is only observable through validate end to end once #2162 and #2163 are also present (otherwise the run crashes at, or aborts before, the later checks), so the unit test is its standalone verification here.

[ArturWieczorek]

Tests Logs:
pr2171-dbtool-validate-check-bugs-test-results.md