Restore eth_getLogs range reduction after alloy migration

[datanexus-vincent]

Problem

log_stream shrinks the eth_getLogs block range when a provider rejects a request as too heavy. It detected that by substring-matching the rendered error against a list that included ServerError(-32005) and ServerError(-32000). Those are rust-web3's Debug rendering of the error code.

Since the alloy migration in v0.42.0 the error is an alloy RpcError, which renders as error code -32005: ... or ErrorResp(ErrorPayload { code: -32005, .. }). The code fingerprints never match. A provider with a range or result cap below GRAPH_ETHEREUM_MAX_BLOCK_RANGE_SIZE now gets ten identical retries, Unexpected RPC error, and a block stream restart, and the subgraph never advances. Besu with --rpc-max-logs-range is the simplest reproduction.

Change

The substring list is replaced by a structural check of the alloy error. A known cap message means the request is over the provider's cap: it is not retried, and log_stream shrinks the range at once. Everything else is retried and then surfaced, exactly as before, and the polling block stream lowers its own range in response, so a cap under an unlisted message still converges the way it does on master.

Caps are matched by message, not code. geth and reth report a cap under -32602 and Alchemy under -32600, which they also use for genuinely malformed requests, so the code alone cannot be trusted. The old list's code-based entries (-32005, -32000) are gone for the same reason: providers also use them for rate limits and transient failures, and shrinking on those sends more requests at a provider that is already refusing them.

Cap messages are also read from HTTP 400, 403, 413 and 503 bodies, and from 200 bodies alloy failed to deserialize. graph-node's HTTP transport turns any non-2xx response into an HttpError carrying the raw body, so a provider that pairs its cap with an error status was otherwise invisible. Ankr does this with a 413, GetBlock with a 403.

Covered, each with its verbatim message in the tests: geth, reth, Besu, Alchemy, Infura, QuickNode, Ankr, zkSync Era, Monad, Dwellir, GetBlock. Other providers can be added without a release through a new GRAPH_RPC_ETH_GET_LOGS_ERRORS variable, a ;-separated list of message fragments, mirroring GRAPH_RPC_ETH_CALL_ERRORS.

Behaviour

Error	Before this PR	After this PR
Known cap message, any code or status	Retried 10x, surfaced, stream restarts; indexing loops	Range shrinks immediately
Cap message only in an HTTP error body or an undeserializable body	Same as above	Range shrinks immediately
Cap under an unlisted message	Same as above	Unchanged: retried, surfaced, polling stream lowers its range and backs off
-32000, -32005 or bare 503 without a cap message	Retried, surfaced	Unchanged. Pre-alloy these shrank the range; that is not restored
Client-side timeout	Retried, surfaced	Unchanged

The reduction policy itself, dividing the step by ten down to a single block, is untouched.

Testing

Unit tests cover every message fragment in isolation, the verbatim provider messages under their real codes, codes that must not match on their own, cap messages inside HTTP and undeserializable bodies, and statuses whose bodies must not be read.

cargo test -p graph-chain-ethereum, cargo clippy -p graph-chain-ethereum --all-targets and cargo check -p graph-chain-ethereum --release pass. The provider messages come from client sources and provider documentation, not from live requests.

[dimitrovmaksim]

From what I see in the PR, the TooHeavy path looks good. I'm not sure about the MaybeTooHeavy one. Details are in the inline comments

-EDIT-

Also please follow the commit convention
https://github.com/graphprotocol/graph-node/blob/master/CONTRIBUTING.md#commit-messages-and-pull-requests
https://github.com/graphprotocol/graph-node/blob/master/CLAUDE.md#commit-convention