DeepSeekChatModel: role field sent as uppercase "USER", causes 422 error

When using the DeepSeekChatModel.call() method in Spring AI (non-streaming mode), the following error occurs:
HTTP 422 - Failed to deserialize the JSON body into the target type: messages[0].role: unknown variant USER, expected one of system, user, assistant, tool

Bug description
After debugging, I found that the role field in the request body is set as "USER" (uppercase), but DeepSeek (which follows OpenAI-compatible format) expects lowercase values such as "user", "assistant", "system", etc.

Environment

• Spring AI version: v1.0.1
• Spring Boot version: 3.2.5
• JDK version: 21

Steps to reproduce

1. Set up a DeepSeekChatModel with a valid API key.
2. Use call() to make a non-streaming chat completion request.
3. Observe the error response (HTTP 422).
   spring:
   ai:
   deepseek:
   api-key: sk-xxx
   base-url: https://api.deepseek.com
   chat:
   options:
   model: deepseek-chat

Expected behavior
The role field in the generated message should be lowercase (e.g. "user"), in compliance with OpenAI/DeepSeek schema.

Minimal Complete Reproducible example
@Test
void testDeepSeekChatCallRoleCaseIssue() {
// This is a simplified example showing the issue in non-streaming mode
DeepSeekChatModel model = new DeepSeekChatModel(
new DeepSeekApi("sk-xxx", RestClient.builder()
.baseUrl("https://api.deepseek.com") // OpenAI-compatible base URL
.build()
)
);

// Single-turn request using .call(), fails with HTTP 422 due to role casing
Prompt prompt = new Prompt(List.of(new Message(Role.USER, "Hello")));
ChatResponse response = model.call(prompt);

}
HTTP 422 - Failed to deserialize the JSON body into the target type: messages[0].role: unknown variant USER, expected one of system, user, assistant, tool

Start at DeepSeekChatModel.call() and inspect how the Prompt messages are serialized for non-streaming requests. Reproduce the issue with the supplied DeepSeekChatModel example, then verify that generated roles use lowercase values accepted by DeepSeek and that the request no longer returns HTTP 422.