The RPC client does not differentiate between retryable and non-retryable error codes, retrying permanently-failing requests unnecessarily

[Lost-Z]

Summary

crates/lumenqraph-indexer/src/rpc_client.rs handles Soroban RPC JSON-RPC error responses but applies the same retry logic to all error codes. The -32001 processing limit error is specifically tracked, but errors like -32602 (Invalid params) or -32601 (Method not found) are permanent failures — retrying them wastes cycles and delays detection of configuration errors. The indexer will retry a permanently misconfigured RPC call up to its backoff ceiling.

Expected Behavior

Permanent RPC errors (invalid params, method not found, invalid contract ID) should not be retried and should surface as configuration errors immediately.

Proposed Solution

• Define an enum of Soroban RPC error codes distinguishing retryable (server-side, transient) from non-retryable (client-side, permanent)
• Non-retryable errors should propagate immediately as anyhow::Error without triggering the backoff loop
• Add a test asserting non-retryable errors are not retried

Affected Files

• crates/lumenqraph-indexer/src/rpc_client.rs
• crates/lumenqraph-indexer/src/poller.rs