fix(bfa): scan FundsIn logs from the asset genesis in bounded ranges

[nklyy]

Problem

BFA receive validation fetched every Bridge FundsIn log with eth_getLogs(fromBlock 0x0, toBlock latest). The public Arbitrum One RPC now refuses ranges over 10M blocks (-32602 query spans N blocks ... only 10000000 are allowed). So every BFA receive fails, and the transfer stays WaitingCounterparty with the error only in RefreshedTransfer.failure.

Fix

EthClient::funds_in_logs_since(contract, genesis_ts) replaces the full scan:

1. It reads the head (eth_blockNumber).
2. It binary-searches the first block mined at or after the asset genesis timestamp minus one day (eth_getBlockByNumber, about 29 calls on Arbitrum One).
3. It scans from that block to the head in ranges of at most 10M blocks. When the node answers with a JSON-RPC error, it halves the range down to 1000 blocks. Transport errors are not retried.

Starting at the genesis drops nothing a mint can use: a mint OpId commits to the contract id, so no FundsIn naming it can be older than the genesis. The one-day slack covers issuer clock skew. Fewer events can only make the cea check stricter, never looser.

The get_logs / client_version JSON-RPC plumbing is merged into one call helper. client_version sends the same request as before.

This is a quick patch until we migrate to upstream rgb-lib.

Tests

• Unit tests for the binary search (bounds, equal timestamps, past the head) and for the chunked scan (contiguous ranges, halving the range actually sent, giving up at the floor, no retry on transport errors, empty range).
• An end-to-end mock RPC test for the whole lookup.
• Manually against the live arb1 RPC and the dev Bridge (0xc7faf6fa…): both FundsIn logs of 2026-10-06 were found in about 5 s, where the old query is refused.
• cargo clippy in all four CI feature sets.