Fix model binding broken by Spring AI 2.0 options merge removal

[igordayen]

OVERVIEW

---

Problem

Spring AI 2.0 removed the implicit merge between per-request ChatOptions and the ChatModel bean's configured default options.
Every provider's OptionsConverter implementation omits .model() from the builder, relying on the old merge to stamp the correct model.

Example — Anthropic: AnthropicOptionsConverter.convertOptions() never calls .model(), so every call produces
AnthropicChatOptions with DEFAULT_MODEL = "claude-haiku-4-5" regardless of which model was selected. The
AnthropicChatModel bean had claude-sonnet-4-5 in its configured default properties options — in 1.x that won; in 2.0 it is never consulted.

Fix

Added buildChatOptions(llmOptions) to SpringAiLlmService that stamps this.name (the configured model ID) onto the
converted options after conversion:

  fun buildChatOptions(llmOptions: LlmOptions): ChatOptions =
      optionsConverter.convertOptions(llmOptions).mutate().model(name).build()

This is provider-agnostic — name is the model ID set at SpringAiLlmService construction time, independent of whatever default any converter bakes in.

Applied at all call sites that build per-request options:

• SpringAiLlmService.createMessageSender and createMessageStreamer
• ChatClientLlmOperations.createMessageSender (override — the actual Anthropic/non-streaming call path; the fix in
  SpringAiLlmService alone is bypassed here)
• Two additional sites in ChatClientLlmOperations (lines 351, 510)
• Two sites in StreamingChatClientOperations (lines 177, 349)

Tests

• SpringAiLlmServiceTest.BuildChatOptionsTests — unit tests for model stamping and field preservation
• ChatClientLlmOperationsTest.ModelBinding — proves model name travels through the ChatClientLlmOperations override
  path to ChatModel.call()
• AnthropicModelBindingTest — Anthropic-specific regression: AnthropicOptionsConverter + buildChatOptions produces
  AnthropicChatOptions with the configured model, not DEFAULT_MODEL

---

Closes: #1815 , #1735 , #1816

[alexheifetz]

Decision needed on cohesiveness of semantics requireSpringAiLlm(llm).optionsConverter
vs requireSpringAiLlm(llm).buildXYZ

[igordayen]

Decision needed on cohesiveness of semantics requireSpringAiLlm(llm).optionsConverter vs requireSpringAiLlm(llm).buildXYZ

Addressed :

1. Added 2-arg function convertOptions (model is a second arg) to OptionConverter
2. Renamed buildXyz into convertOptions to retain similar naming conventions (and reduce cognitive load for developers:))
3. Marked the 1-arg function convertOptions as DEPRECATED
4. Provided proper comments / TODO

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud