Add a circuit breaker around internal/soroban/client.go RPC calls

[Jagadeeshftw]

📌 Description

internal/soroban/client.go calls out to Soroban RPC for every escrow/payroll-related read or write. If the RPC endpoint degrades, retrying every caller independently can pile up latency and load. A simple circuit breaker would fail fast once the endpoint is clearly unhealthy.

🧩 Requirements and context

• Add a circuit breaker (open/half-open/closed) around outbound RPC calls, tripped after N consecutive failures within a window.
• While open, fail fast with a typed error rather than attempting the call.
• Periodically probe (half-open) to detect recovery.

🛠️ Suggested execution

• Wrap the RPC call sites in internal/soroban/client.go (or rpc.go) with a circuit breaker (small hand-rolled or a lightweight existing dependency if already vendored).
• Expose breaker state via internal/metrics/metrics.go.
• Add a test simulating consecutive failures and asserting the breaker opens, then recovers on a successful probe.

✅ Acceptance criteria

• Breaker opens after a configurable consecutive-failure threshold.
• Calls fail fast while open instead of hanging on further RPC attempts.
• Breaker state is observable via metrics; recovery is tested.

🔒 Security notes

No direct security impact; primarily an availability/resilience improvement to avoid cascading failure when the RPC endpoint is degraded.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[thlpkee20-wq]

Please consider assigning this issue to me, as I’m prepared to contribute wherever it’s needed, whether that involves protocol logic, interface creation, service-layer development, visual implementation, or cross-component coordination.

[Jagadeeshftw]

Assigned! Go ahead and open a PR referencing this issue (Closes #125) when ready. t.me/+vTbe0hOUKrFhNTJl