Critical: Stellar RPC failover, retries, and circuit breaker

[robertocarlous]

---

Labels: priority/critical, area/stellar, area/infra, feature

Body:

## Summary
All on-chain reads/writes depend on a single `STELLAR_RPC_URL`. If the RPC endpoint is slow or down, the event listener, vault contract calls, and transaction confirmation polling will fail — taking down readiness and blocking deposits/withdrawals.

## Problem
`src/stellar/client.ts` creates one singleton RPC server:

```ts
let rpcServer: rpc.Server | null = null;

export function getRpcServer(): rpc.Server {
  if (!rpcServer) {
    rpcServer = new rpc.Server(RPC_URL);
  }
  return rpcServer;
}


## Acceptance criteria

 Multi-endpoint RPC configuration documented in .env.example
 Failover occurs automatically when primary RPC fails
 Circuit breaker prevents request storms to unhealthy endpoints
 Event listener and contract module use shared resilient client
 Metrics exposed on /metrics for RPC health
 Tests cover: primary success, failover on primary failure, circuit open behavior
 Runbook documents how to rotate RPC providers

[OlaGreat]

I'd like to take this on.

I'm a software engineer with blockchain and cryptography experience. I'm comfortable with JavaScript crypto primitives (Web Crypto API / Node.js crypto module) and understand why raw identifiers must never be stored or logged. Happy to follow the project's existing patterns and include tests for the acceptance criteria.