fix(jsonrpc): enforce maxBlockRange on eth_getFilterLogs

[0xbigapple]

What does this PR do?

Applies the jsonRpcMaxBlockRange cap to eth_getFilterLogs, closing a gap where the block-range limit could be bypassed via the filter path.

eth_getLogs builds its LogFilterWrapper with checkBlockRange=true, so the cap is enforced. But eth_newFilter builds the wrapper with checkBlockRange=false, and eth_getFilterLogs reuses that stored wrapper without re-checking — so the cap was never applied when querying logs through a filter. A client could create a filter with a wide range (e.g. fromBlock=0x0, toBlock far ahead) and call eth_getFilterLogs to trigger an unbounded historical scan (CPU/IO pressure, potential OOM).

Changes:

• Extract the range check from the LogFilterWrapper constructor into a reusable validateBlockRange(currentMaxBlockNum) method (logic and error message unchanged).
• eth_getFilterLogs now calls validateBlockRange against the current head before scanning, mirroring eth_getLogs.
• Declare JsonRpcInvalidParamsException on the getFilterLogs impl (the interface and its @JsonRpcError(code=-32602) mapping already declared it).

Creation-time behavior is intentionally left unchanged: eth_newFilter still accepts wide ranges (no creation-time gate), matching geth's "creation accepts, query enforces" model and preserving forward polling via eth_getFilterChanges (which does not scan a range).

Why are these changes required?

Without this, jsonRpcMaxBlockRange only protects eth_getLogs; the eth_newFilter + eth_getFilterLogs path silently bypasses it, leaving a DoS vector on full nodes with JSON-RPC enabled.

This PR has been tested by:

• Unit Tests
• Manual Testing

Follow up

Extra details