fix(rpc): return -32602 error for eth_getLogs with pending block tag

[osr21]

Problem

Closes #426.

When eth_getLogs is called with "fromBlock": "pending" or "toBlock": "pending", Reth resolves "pending" as head + 1 and returns an empty array []. Arc intentionally hides all pending-block state for public RPC nodes, so returning [] silently misleads callers into thinking no logs exist at the current head.

Solution

Add a pending_logs_error guard in NoPendingTransactionsRpcMiddleware::intercept_or_forward that detects "pending" tags in eth_getLogs filter params and returns a -32602 Invalid params error:

{
  "code": -32602,
  "message": "\"pending\" block tag is not supported for eth_getLogs on Arc; use \"latest\" instead"
}

This is consistent with how the middleware already handles other pending-block RPCs — rejecting with a structured error rather than returning a misleading empty or null result.

Changes

crates/evm-node/src/rpc_middleware.rs

• Added ETH_GET_LOGS_METHOD and PENDING_LOGS_ERROR_CODE constants
• Added pending_logs_error() that parses filter params for pending fromBlock/toBlock (positional and object-form; case-insensitive; decoupled from Alloy proc-macro field names)
• Wired into intercept_or_forward before the null-response path

Testing

Existing middleware unit tests cover the intercept_or_forward dispatch path. A targeted test for the new guard can be added as a follow-up using the in-module MockRpcService harness.

[github-actions]

Hi @osr21,

Thank you for your interest in contributing to Arc Node.

This PR has been automatically closed because you are not assigned to issue #426. We require contributors to be explicitly assigned to an issue before submitting a PR.

To contribute properly:

1. Comment on issue eth_getLogs: pending block tag resolves to head+1 instead of coercing to latest #426 requesting assignment
2. Wait for maintainer approval
3. Only submit a PR after you have been assigned

Please see our CONTRIBUTING.md for more details.