eth_getLogs "pending" resolves to head+1 instead of latest, non-deterministic #446

Every other method with a block tag resolves "pending" to "latest" when there's no pending block (even asserted by our own MEV suite check_pending_eq_latest in mev.rs). eth_getLogs is the exception: it resolves "pending" to head + 1, a block that may not exist yet — so results are non-deterministic depending on timing. Confirmed live, batching one JSON-RPC call so head can't move mid-request: same head (61053305→61053305), same request, one run returns [61053306] (doesn't exist yet), another run at head 61053314 returns [61053314] (== head).

Fix: normalize fromBlock/toBlock from "pending" to "latest" in the filter object at the middleware layer, same as everywhere else. blockHash-form filters and EIP-1898 object params untouched (not applicable here). Already implemented with tests (array-form, object-form, no-op cases) see #340 (closed only because it predated the current contribution policy, not on the merits) — happy to open a fresh PR once assigned.