fix(jsonrpc): restrict result size of FilterResult

[317787106]

What does this PR do?

Caps pending results at 20,000 entries per JSON-RPC log or block filter. A filter at exactly the limit remains readable. If an incoming batch would exceed the limit, the filter is invalidated, its backlog is cleared, and subsequent events are ignored for that filter.

Reads through eth_getFilterChanges or eth_getFilterLogs then return error -32005, with message filter result limit exceeded; filter invalidated and structured data:

{"reason":"FILTER_OVERFLOW","limit":20000}

The shared FilterResult implementation synchronizes append, drain, expiration, and close operations. Overflow records retain their original expiration deadline and count toward existing filter limits; failed polls cannot renew them. Other filters continue receiving events. Uninstalling a filter or closing the service releases retained results and prevents stale writers from refilling closed filters.

Why are these changes required?

Clients that stop polling can accumulate results until filter expiration. Existing filter-count limits and shared log objects do not cap the queue entries retained by each filter. Explicit invalidation makes a result gap visible to clients while limiting each filter's backlog.

This PR has been tested by:

• Local validation on ARM64 / JDK 17: 80 tests passed across eight classes, including 35 new cases.
• Coverage includes the exact limit, single-entry and batch overflow, concurrent append/poll behavior, expiration without renewal, uninstall/close cleanup, registration caps, Full/Solidity routing, serial/parallel dispatch, and JSON-RPC error serialization.
• Existing filter dispatch, concurrent polling, error resolver, wallet cursor, and JSON-RPC service regression tests passed.
• ./gradlew checkstyleMain checkstyleTest and git diff --check passed.
• Semgrep: 93 applicable rules across the six changed production files, with no findings.

The full repository test suite and manual node load tests were not run.

Follow up

Validate and tune FilterResult.MAX_RESULT_SIZE using resource tests. The limit is currently a constant and bounds entries per filter; aggregate memory still depends on filter counts and retained payload sizes.

Extra details

Normal request parameters and successful response formats remain unchanged. Clients receiving FILTER_OVERFLOW must recreate the filter and resynchronize from their saved checkpoint. Expired records continue to be removed by the existing event-dispatch cleanup; no additional cleanup scheduler is introduced.