feat: add exponential backoff retry for transient provider errors

[ramparte]

Problem

Provider rate limit errors (HTTP 429) and transient failures cause sessions to crash immediately, even though these errors are inherently temporary and resolve on retry.

Solution

Added a _call_provider_with_retry() method to the streaming orchestrator that wraps all 3 provider call sites with configurable exponential backoff:

• Retries only retryable errors: Checks LLMError.retryable flag (True for RateLimitError, ProviderUnavailableError, LLMTimeoutError)
• Exponential backoff: base_delay * 2^attempt, capped at max_delay
• Honors retry_after: Uses server-provided delay when available (e.g., from 429 responses)
• Observable: Emits provider:retry events on each retry attempt
• Configurable: Three config knobs with sensible defaults

Configuration

Config Key	Default	Description
retry_max_attempts	3	Maximum retry attempts (0 to disable)
retry_base_delay_seconds	1.0	Base delay for exponential backoff
retry_max_delay_seconds	30.0	Maximum delay cap

Call sites modified

1. Non-streaming fallback (provider.complete()) - main execution loop
2. Max-iterations fallback (provider.complete()) - graceful degradation path
3. Streaming (provider.stream()) - primary streaming path

Test coverage

18 new tests covering all retry behaviors. All 53 tests pass (18 new + 35 existing, zero regressions).

🤖 Generated with Amplifier