Refactor retry logic and reduce code duplication

[ndenev]

Summary

• Extract progress handling into handle_progress_update() function in repl.rs to reduce nesting
• Create ExecutionMetrics struct to group metrics parameters (avoids too_many_arguments lint)
• Add generic retry_with_backoff() function with exponential backoff and ±25% jitter
• Add resolve_context() helper to deduplicate context resolution logic
• Consolidate test filter helpers with binary_filter() in provider.rs tests
• Add fastrand dependency for retry jitter randomization

Test plan

• Verify build passes with cargo build
• Verify tests pass with cargo test
• Verify clippy is clean with cargo clippy
• Manually test REPL with multi-cluster queries to confirm progress display works
• Manually test retry behavior by querying with intermittent network issues

[claude]

Code review

Issue: Retry logic violates CLAUDE.md specification

The retry logic changes in src/kubernetes/client.rs violate the documented behavior in CLAUDE.md.

CLAUDE.md specifies:

Connection and discovery failures retry 3 times with linear backoff (100ms, 200ms, 300ms)

This PR changes:

1. Number of retries: 3 → 5 attempts (MAX_RETRY_ATTEMPTS = 5)
2. Backoff strategy: Linear → Exponential with jitter
   • Old: 100ms, 200ms, 300ms (linear, ~600ms total)
   • New: ~100ms, ~200ms, ~400ms, ~800ms, ~1600ms (exponential, ~3100ms total)

Impact:

• Maximum retry time increases from ~600ms to ~3.1 seconds (5x longer)
• This affects timeout behavior and scripting predictability that CLAUDE.md explicitly documents
• Violates CLAUDE.md Priority Bump serde_json from 1.0.147 to 1.0.148 #1: "Any deviations from standards, best practices, or established patterns must be discussed before implementation"

Resolution:
Either:

1. Revert retry logic to match CLAUDE.md (3 attempts, linear backoff), OR
2. Update CLAUDE.md first to document the new behavior with justification

See:

k8sql/src/kubernetes/client.rs

Lines 33 to 56 in eda3af2

	/// Maximum retry attempts for transient failures
	const MAX_RETRY_ATTEMPTS: u32 = 5;
	/// Base delay for exponential backoff (100ms base: 100ms, 200ms, 400ms, 800ms, 1600ms)
	const RETRY_BASE_DELAY_MS: u64 = 100;
	/// Jitter factor (±25% of delay to prevent thundering herd)
	const RETRY_JITTER_FACTOR: f64 = 0.25;
	/// Calculate delay with exponential backoff and jitter
	///
	/// Returns a delay with ±25% random jitter to prevent synchronized retries
	fn calculate_retry_delay(attempt: u32) -> Duration {
	let base_delay_ms = RETRY_BASE_DELAY_MS * 2u64.pow(attempt);
	// Add jitter: ±25% of base delay
	let jitter_range = (base_delay_ms as f64 * RETRY_JITTER_FACTOR) as u64;
	let jitter = if jitter_range > 0 {
	fastrand::u64(0..jitter_range * 2) as i64 - jitter_range as i64
	} else {
	0
	};
	let delay_ms = (base_delay_ms as i64 + jitter).max(10) as u64; // minimum 10ms
	Duration::from_millis(delay_ms)
	}

---

Note: The exponential backoff with jitter is arguably a best practice improvement over linear backoff, but it should be discussed and documented before implementation per the project's correctness-first philosophy.