feat(api/client): support multi-endpoint DA reads for resilience

[walldiss]

Summary

The api/client library's ReadConfig accepts a single BridgeDAAddr string for DA reads. If that endpoint becomes unavailable, all read operations (share, header, blob, fraud, blobstream) fail with no fallback. There is no support for multiple endpoints, failover, or automatic reconnection.

Current Behavior

ReadConfig takes one endpoint:

type ReadConfig struct {
    BridgeDAAddr string
    DAAuthToken  string
    HTTPHeader   http.Header
    EnableDATLS  bool
}

Each module connects independently to the same single address via JSON-RPC:

jsonrpc.NewClient(ctx, cfg.BridgeDAAddr, "share", ...)
jsonrpc.NewClient(ctx, cfg.BridgeDAAddr, "header", ...)
jsonrpc.NewClient(ctx, cfg.BridgeDAAddr, "blob", ...)

If the endpoint is unavailable, client initialization fails entirely — no partial degradation, no retry.

Desired Behavior

Support configuring multiple DA endpoints so reads are resilient to individual endpoint failures.

Possible Approaches

1. Failover list — try endpoints in order, move to next on failure/timeout
2. Parallel reads — race requests to all endpoints, take first success
3. Health-check routing — periodically probe endpoints, route to healthy ones
4. Round-robin with retry — distribute load across endpoints, retry failures on alternates

Open to other ideas — the right approach may depend on typical deployment patterns and latency tolerance.

Scope

• api/client/read_client.go — ReadConfig and NewReadClient()
• Potentially a shared multi-endpoint transport layer that wraps go-jsonrpc

See also: #4856 for the equivalent gap in state/core_access.go (consensus reads).