feat(ethereum): build correctness-preserving RPC provider failover state machine

[Meet-hybrid]

Closes #1027

Summary

Provider rotation and retries were not a state machine: concurrent callers could rotate inconsistently, timeout timers could outlive requests, and a response from a lagging provider could update shared block state after a newer response. This PR replaces the ad-hoc failover()/getProvider() rotation in EthereumRpcClient with per-chain provider circuits that make failover deterministic and correctness-preserving.

What changed

New module backend/src/services/ethereum/failover/:

• errors.ts — error taxonomy that separates transport, timeout, rate_limit, provider_lag, invalid_data, and application failures (incl. ethers.js code mapping). Application errors are per-query outcomes and never rotate providers.
• timeout.ts — cancellation-safe deadline: the timer is always cleared on settlement (no leaks) and the underlying task receives an AbortSignal so work is cancelled where the transport supports it; late-settling tasks cannot produce unhandled rejections.
• circuit.ts — per-provider health state machine: healthy → degraded → cooling_down/unhealthy, consecutive-failure thresholds, cooldowns, idle health decay, and exported recovery criteria (failuresToRecover, recoveryEtaMs) with reason codes.
• chainCircuit.ts — the per-chain circuit: generation tokens so late responses from superseded leases can never regress the accepted head/evidence; deterministic failover (lowest healthy index wins; sticky active while all providers are down) so concurrent decisions converge; header monotonicity (heights only advance; a lagging current provider is penalized); and request hedging for critical reads. All transitions are synchronous, so Node's single thread guarantees a consistent snapshot across concurrent callers.

Reworked EthereumRpcClient to drive all calls through the circuit:

• getBlockNumber, "latest" blocks, and getBridgeReserves are hedged and feed the monotonicity guard.
• Contract calls are bound to the selected provider inside the request, so a mid-request failover can never bind a contract to a stale provider (previously getBridgeReserves/getTokenInfo captured the provider before the retry/failover window).
• Circuit events are surfaced as structured logs plus rpc_failover_total / rpc_all_providers_down_total metrics.
• New introspection: getProviderStates(chainId) (recovery criteria + reason codes), getActiveProviderIndex(chainId); getLastKnownBlock now reads the circuit's monotonic accepted head.

Also fixes two pre-existing ESLint errors (prefer-const, no-useless-escape) that were failing the CI lint step on main.

Acceptance criteria

• Late responses cannot regress last-known block or accepted evidence — generation-gated commit path + monotonicity guard, tested.
• Concurrent failover decisions converge deterministically — lowest-healthy-index rule + sticky active, tested under a 20-caller thundering herd.
• Timeouts cancel underlying work where supported and do not leak timers — withTimeout clears its timer on every settlement path; timer-leak tests with fake timers.
• Provider states expose recovery criteria and reason codes — ChainCircuitSnapshot.providers[] exposes state, reason, failuresToRecover, recoveryEtaMs, ready.
• Fault injection — unit tests cover partitions, stale success/lag, flapping providers (bounded oscillation), and thundering herds.

Testing

• New: 50 unit tests in backend/tests/services/ethereum/failover/ (all passing).
• npm --workspace=backend run lint passes.
• npm --workspace=backend run build adds zero new TypeScript errors (the 35 pre-existing errors on main are untouched).
• Full backend unit suite: no regressions vs main (identical pre-existing failures, which are DB-environment dependent).

Notes

CI on main is currently failing before jobs start (GitHub "workflow file issue") and the backend build already fails on 35 pre-existing type errors unrelated to this change. Neither is introduced by this PR.

[Mosas2000]

In errors.ts, mutating the existing error object via error.providerIndex = providerIndex inside toRpcError introduces a side-effect that could cause unexpected behavior if the same error instance is caught and reused elsewhere.

[Mosas2000]

Consider returning a new cloned RpcCallError instance instead of modifying the existing one to maintain strict state immutability and ensure all checks are passing.