docs: document eth_getLogs query limits

[huklaa]

Summary

• document the inherited --rpc.max-blocks-per-filter and --rpc.max-logs-per-response flags
• record their Reth defaults of 100000 blocks and 20000 logs
• clarify that public gateways and reverse proxies may enforce stricter limits independently

This captures the repo-owned documentation follow-up identified in #83 without changing node behavior or duplicating the pending-tag fix in #340.

Validation

• git diff --check

Related to #83.

[huklaa]

Checking comment permissions after the latest CI update. No code changes needed from my side right now.

[osr21]

One addition worth capturing: the Arc public mainnet RPC enforces a stricter limit than the Reth node defaults.

Querying https://rpc.mainnet.arc.io with a block range above ~10,000 blocks returns:

{ "code": -32600, "message": "Query exceeds max block range of 10000" }

This is 10× lower than the 100,000-block Reth default this PR documents. A developer who validates against a local Arc node (where the Reth default applies) will hit this in production without a clear reason why — especially since the error code is -32600 (invalid request) rather than the rate-limit or method-not-found codes they might expect.

A note in the "public gateway" section with the concrete 10,000-block figure, alongside the existing mention that gateways may enforce stricter limits, would close that gap. Practical reference: we hit it while fetching DevicePayment event history from a mainnet contract and switched to 5,000-block chunks with cursor tracking to stay safely under the limit.

[huklaa]

The 10,000-block Arc public mainnet RPC limit has been documented in both docs/running-an-arc-node.md and crates/node/README.md, including the -32600 error code and message. The documentation now clearly distinguishes this gateway-enforced limit from the underlying 100,000-block Reth default.

[huklaa]

@romac — the current documentation head `bdb38bebbe048b40e4b8c23417ded1dd6ff3d06d` is still waiting for maintainer approval on [Public CI](https://github.com/circlefin/arc-node/actions/runs/36233966497) and [Build Docker](https://github.com/circlefin/arc-node/actions/runs/36233966475), both `action_required` since September 26. Today's Public CI failure notification is for the superseded September 11 head `26aee9a`; no jobs ran. Could you review and approve the current-head workflows so this documentation change can complete validation?

[osr21]

@huklaa I checked the current head (bdb38be). Public CI and Build Docker are both action_required for this SHA; neither ran. The completed checks shown for this head include successful PR-title, signature, and StepSecurity checks, while release-only jobs are skipped.

So this is an approval gate, not evidence of a failing current-head build. After a maintainer approves those workflows, the results should validate the current docs-only diff; the notification for the superseded 26aee9a head should not be treated as a failure of this head.