Feature Proposal: Add Retry Support to ChatClient Fluent API

Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested.
I have searched existing issues for "retry", "ChatClient retry", "fluent retry" and found no similar feature requests.

Expected Behavior

ChatClient should support retry configuration through its fluent API, similar to how WebClient and RestClient provide retry capabilities.

Proposed API:

// Basic retry configuration
String response = chatClient.prompt("Analyze this data")
    .retry(RetrySpec.builder()
        .maxAttempts(3)
        .backoff(Duration.ofSeconds(1), Duration.ofSeconds(10))
        .build())
    .call()
    .content();

// AI-specific retry conditions
String response = chatClient.prompt("Generate report")
    .retry(RetrySpec.builder()
        .maxAttempts(5)
        .retryWhen(ex -> {
            if (ex instanceof OpenAiRateLimitException) return true;
            if (ex instanceof TokenLimitException) return false; // No point retrying
            return ex instanceof TransientException;
        })
        .exponentialBackoff(Duration.ofSeconds(1))
        .build())
    .call()
    .content();

// Pre-configured retry strategies
String response = chatClient.prompt("Complex analysis")
    .retry(RetrySpec.forProvider("openai")) // Provider-specific defaults
    .call()
    .content();

// Streaming support
Flux<String> stream = chatClient.prompt("Write a story")
    .retry(RetrySpec.forStreaming())
    .stream()
    .content();

Current Behavior

Currently, Spring AI provides retry functionality only at the ChatModel level through properties configuration:

spring.ai.retry.max-attempts=3
spring.ai.retry.backoff.initial-interval=1000ms

However, this approach has several limitations:

1. No fluent API integration: ChatClient's fluent API chain cannot specify retry behavior
2. Global configuration only: Cannot set different retry strategies per request
3. Breaking the fluent pattern: Must wrap ChatClient calls in @Retryable methods
4. No AI-specific retry logic: Generic retry doesn't understand AI provider error types

Current workaround (suboptimal):

@Service
public class AiService {
    
    @Retryable(value = {Exception.class}, maxAttempts = 3)
    public String getResponse(String prompt) {
        return chatClient.prompt(prompt).call().content();
    }
}

Context

How has this issue affected you?
This limitation forces developers to choose between:

1. Using ChatClient's elegant fluent API (but losing retry control)
2. Using @Retryable on wrapper methods (but breaking the fluent pattern)

What are you trying to accomplish?
Building production-ready AI applications that can handle:

OpenAI rate limiting (429 errors) with appropriate backoff
Transient network failures with immediate retry
Provider-specific error handling (token limits vs rate limits)
Different retry strategies for different types of AI operations

What other alternatives have you considered?

1. Method-level @Retryable: Breaks fluent API, requires wrapper methods
2. Manual retry loops: Verbose, error-prone, not idiomatic Spring
3. RestClient with custom interceptors: Complex, bypasses Spring AI abstractions

Are you aware of any workarounds?

Yes, but they're all suboptimal:

• Using @Retryable on service methods breaks the fluent API pattern
• Global retry properties don't allow per-request customization
• Manual retry implementation is verbose and error-prone

Why this feature is important:

1. Consistency with Spring ecosystem: WebClient and RestClient already provide fluent retry APIs
2. Production readiness: AI applications need robust error handling for rate limits and transient failures
3. AI-specific requirements: Different AI providers have different error patterns requiring specialized retry logic
4. Developer experience: Maintains the elegant fluent API while providing powerful retry capabilities

Real-world impact:

• E-commerce product description generation needs rate limit handling
• Customer service chatbots require resilience against transient failures
• Document processing systems need different retry strategies for different AI operations
• Cost optimization through intelligent retry policies (avoiding retries for non-retriable errors)

This feature would make Spring AI much more suitable for production environments while maintaining its developer-friendly API design.

The issue names no files or tests. Start by inspecting the ChatClient fluent API and the existing ChatModel retry configuration, then compare the retry capabilities of WebClient and RestClient. Done would require an agreed scope and implementation for per-request, conditional, provider-specific, and streaming retry behavior.