Align OpenAI-compatible streaming reasoning_content with non-streaming responses

[jewoodev]

Why

OpenAiChatModel already preserves provider reasoning metadata such as DeepSeek's reasoning_content on the non-streaming call() path, but the OpenAI-compatible streaming path drops the same fields before they can be captured in reasoningContent, leaving that metadata empty on streamed responses. ChunkMerger.chunkToChatCompletion rebuilds each streamed chunk's message from content/refusal/toolCalls only, so provider-specific delta fields such as DeepSeek's reasoning_content (or OpenRouter's reasoning) never reach the message that getReasoningContent reads. The next-turn replay in createRequest then has nothing to re-attach, so providers that require reasoning on assistant tool-call messages reject the request with "thinking is enabled but reasoning_content is missing in assistant tool call message".

How

The fix stays inside OpenAiChatModel: chunkToChatCompletion now carries the delta's additional properties onto the rebuilt message (matching the non-streaming path), mergeDeltas concatenates reasoning fragments across merged tool-call chunks, and the streaming pipeline accumulates reasoning per choice so the final emitted response holds the full reasoning content — surviving the last-wins metadata aggregation that MessageAggregator-based advisors use to build the assistant message they re-inject on the next turn. As a consequence, intermediate streamed responses carry the reasoning accumulated so far rather than the per-chunk fragment (previously this metadata was always empty on the streaming path).

Test

Unit tests reproduce the failure with mocked streaming chunks: reasoning followed by a split tool call (parameterized over DeepSeek's reasoning_content and OpenRouter's reasoning) and reasoning without tools. The new regression cases fail on main with empty reasoningContent and pass with this change. The tool-call test also replays the aggregated assistant message through createRequest and asserts the reasoning_content wire field is re-attached:

./mvnw test -pl models/spring-ai-openai -Dtest=OpenAiChatModelTests

The native DeepSeek starter loses reasoning at a different point (MessageAggregator flattening of DeepSeekAssistantMessage, #6026), which this PR intentionally does not touch.

See #5898

[ericbottard]

I'm not very keen on transforming a null into "". If a value isn't there, it isn't there. Or does the downstream code rely on a value being present in all cases?

[jewoodev]

Good point. The downstream replay path only needs the value when actual reasoning content is present, so missing provider fields do not need to be modeled as empty strings here. I updated the merge logic to leave missing fields absent and only concatenate/propagate reasoning fields when the incoming chunk carries a non-empty fragment.