Refactor RobustSubscription to delegate provider management to RobustProvider

Summary

RobustSubscription currently tracks provider state (current_fallback_index, last_reconnect_attempt) and implements reconnection logic (try_reconnect_to_primary, switch_to_fallback). This violates separation of concerns—provider management should be the responsibility of RobustProvider, not the subscription.

Current Problems

1. RobustSubscription knows too much about providers

• Tracks current_fallback_index and last_reconnect_attempt
• Directly calls try_fallback_providers_from and try_provider_with_timeout
• Implements try_reconnect_to_primary logic

2. Reconnection logic is subscription-agnostic

• The periodic reconnection to primary provider is general RobustProvider functionality
• Has nothing to do with subscriptions specifically
• Should be reusable for other operations

3. Tight coupling

• RobustSubscription needs internal knowledge of RobustProvider's fallback mechanism
• Makes both components harder to maintain and test independently

Proposed Solution

RobustSubscription should only:

• Hold the current subscription
• Call recv() and handle timeouts
• Tell RobustProvider: "give me a new subscription" when errors occur

RobustProvider should:

• Track which provider is currently active (primary vs fallback index)
• Track last_reconnect_attempt
• Implement try_reconnect_to_primary logic
• Expose a method like subscribe_blocks_with_failover() that handles all provider switching internally

Start by locating RobustSubscription and RobustProvider, then read the existing fallback and reconnection entry points named in the issue: try_reconnect_to_primary, switch_to_fallback, try_fallback_providers_from, and try_provider_with_timeout. Done means RobustProvider owns provider state and switching, while RobustSubscription only receives subscriptions, handles recv() timeouts, and requests a new subscription through the provider.