## Description 

The transactions table previously had an index on `tx_sequence_number`
so we transformed filters into `tx_sequence_number` to leverage the
index. This is now no longer efficient now that the `tx_sequence_number`
index has been dropped on transactions table in favor of an index on
both `tx_sequence_number` and `checkpoint_sequence_number`, and now that
it is partitioned on checkpoint_sequence_number . The query planner ends
up looking through each transaction partition. This is particularly
noticeable if the filtered transactions are spread across partitions.

Since the initial graphql request without the cursor completes in a
reasonable amount of time, we can narrow improvements down to when
cursors are provided.

1. transaction cursor carries the `checkpoint_sequence_number` when the
transaction was finalized. Instead of just filtering `>=` or `<=` on
`tx_sequence_number`, we also filter on the `checkpoint_sequence_number`
when the transaction was finalized.
2. Drop all checkpoint_sequence_number → tx_sequence_number conversions
so we can leverage the partitions and index on checkpoint. For queries
that involve filters on both tx and checkpoint sequence number, it'll
also hit an index.

## Test Plan 

Existing tests should pass
Cleaned up test logic for `consistency/epochs/transaction_blocks.move`

---
If your changes are not user-facing and do not break anything, you can
skip the following section. Otherwise, please briefly describe what has
changed under the Release Notes section.

### Type of Change (Check all that apply)

- [ ] protocol change
- [ ] user-visible impact
- [ ] breaking change for a client SDKs
- [ ] breaking change for FNs (FN binary must upgrade)
- [ ] breaking change for validators or node operators (must upgrade
binaries)
- [ ] breaking change for on-chain data layout
- [ ] necessitate either a data wipe or data migration

### Release notes