WS subscription lost after provider idle disconnect — backfill blocks reconnect for up to 60s

[tarasverq]

Summary

When a WebSocket provider closes an idle connection (had_active_traffic=false), lasso fails to recover the subscription automatically — even when other healthy providers are actively serving requests. Manual intervention (container restart) was required to restore the subscription.

Observed behavior

1. Provider disconnects with {:remote_closed, "TCP connection closed abruptly"}, was_stable=true, had_active_traffic=false
2. Lasso initiates backfill routed strictly by priority order
3. The selected backfill provider is unresponsive — HTTP → timeout (30s) → retry WS → timeout (30s) = 60s blocked per provider
4. Other providers in the pool are healthy and actively serving regular RPC requests during this entire time, but are not selected for backfill
5. During the 60s block, other WS connections degrade, exhausting the pool
6. Lasso emits No available WS channels / Subscription failed: No available providers and does not re-attempt subscription recovery
7. Subscription remains dead until manual restart

Expected behavior

Lasso should automatically recover the subscription by resubscribing on any available healthy provider. A failed backfill attempt should not permanently block subscription recovery.

Suggested fixes

1. Automatic resubscription after total pool failure — if all providers fail during recovery, retry subscription establishment on the next healthy provider rather than giving up
2. Health-aware backfill provider selection — use the same health-tiering logic applied to regular requests when selecting a backfill provider
3. Fail fast during backfill — if HTTP times out, skip remaining transports on that provider and move to the next
4. WS keepalive / ping interval config — a configurable ws_ping_interval_ms would prevent idle disconnects on providers with outbound-traffic-only idle timers