fix: collect high-value RAVs before dust and expose deferrals

[MoonBoi9001]

This PR makes both TAP collectors reconcile their most valuable pending Receipt Aggregate Vouchers (RAVs) first, raises the per-pass batch from 100 to 1,000 rows, and makes deferred fees visible to operators.

Each pass, the collectors take a capped batch of pending RAVs and reconcile it against the chain: recording which were collected, finalizing settled ones, and clearing the rest for submission. The batch was 100 rows in unspecified database order, while RAVs below the redemption threshold (1 GRT by default) legitimately never leave the pending set, so permanently deferred rows could fill the batch and starve reconciliation for everything behind them. That matters more alongside #1247, which stops the agent from wrongly finalizing partially collected RAVs, so their below-threshold remainders now stay pending instead of being written off.

The parts:

• pendingRAVs orders by value descending, so dust sinks to the bottom of the batch, and warns when the batch comes back full.
• The batch limit rises from 100 to 1,000. The allocation id filter sent to the subgraph is chunked into groups of 100 per request, keeping request bodies the size they are today (larger bodies have drawn http 413 rejections from this endpoint before).
• New Prometheus gauges report the count of below-threshold RAVs deferred each pass and their total GRT; for Horizon (TAP v2) that value is what is still collectible, the RAV's total minus what the payer already collected. The existing info log gains the same remainder figure.

6 Postgres-backed tests cover the ordering, the full-batch case, and the chunked, block-pinned subgraph queries.