fix: handle thinking model reasoning-only responses as valid content

[neorrk]

Summary

Thinking models (Kimi K2.5, DeepSeek-R1, QwQ, etc.) often produce responses containing only reasoning_content with no regular text content or tool_calls. This triggers the "The language model did not provide any assistant messages" error and unnecessary retries, even though the model did respond — just entirely in reasoning tokens.

This PR fixes five issues:

1. Reasoning-only responses treated as empty (Task.ts — first content gate)

When a thinking model returns only reasoning_content (no text, no tool calls), hasTextContent is false and hasToolUses is false, causing the response to be treated as completely empty. The fix adds hasReasoningContent to the validity check at line 3416 so reasoning-only responses are recognized as valid model output.

2. Second content gate missing hasReasoningContent (Task.ts — line 3567)

The first content gate was updated to include hasReasoningContent, but the second gate at line 3567 was not. This caused reasoning-only responses to save an assistant message to history but then fall through to the "no assistant messages" error path, incrementing consecutiveNoAssistantMessagesCount and leaving an orphaned assistant message in conversation history. Both gates now consistently check hasReasoningContent.

3. pWaitFor hang on reasoning-only responses (Task.ts)

When only reasoning content is present, assistantMessageContent is empty and presentAssistantMessage is never called, so userMessageContentReady stays false — causing pWaitFor to block forever. The fix sets userMessageContentReady = true directly when assistantMessageContent is empty, allowing the flow to proceed to the didToolUse check which will correctly prompt the model to use tools.

4. Missing reasoning field support in OpenAI streaming handler (openai.ts)

Ollama's /v1/chat/completions endpoint sends reasoning tokens under the reasoning field (not reasoning_content). The streaming handler only checked for reasoning_content, so users connecting through Ollama would lose all thinking output. The fix handles both field names.

5. Missing reasoning in non-streaming responses (openai.ts)

The non-streaming path didn't yield reasoning_content or reasoning at all, so thinking model responses via non-streaming mode would lose their reasoning output.

How It Was Discovered

Running Kimi K2.5 through an Ollama backend via the OpenAI Compatible provider. The model frequently returns reasoning + tool_calls with zero content text. Without this fix, every such response triggers the empty response error and retry loop, making the model unusable.

Test Plan

• All 5233 existing tests pass (362 test files, 0 failures)
• All pre-commit hooks pass (lint, prettier, type-check)
• New unit tests for Ollama streaming patterns (NativeToolCallParser: 5 tests for single-chunk tool calls, finalization, multiple sequential calls)
• New unit tests for OpenAI handler reasoning support (4 tests: reasoning_content, reasoning field, single-chunk tool call with non-standard ID, non-streaming reasoning + tool calls)
• Verified both content gates (lines 3416 and 3567) consistently check hasReasoningContent
• Verified pWaitFor does not hang when assistantMessageContent is empty (reasoning-only response)
• Manual test with Kimi K2.5 via Ollama /v1/chat/completions — reasoning-only responses no longer trigger "no assistant messages" error or hang
• Manual test with DeepSeek-R1 via OpenAI Compatible — reasoning is properly captured in both streaming and non-streaming modes

Fixes #10603
Related: #9959, #10064, #9551

🤖 Generated with Claude Code

[roomote]

Rooviewer   See task

Both previously flagged issues are now resolved. The pWaitFor hang is fixed by setting userMessageContentReady = true directly when assistantMessageContent is empty.

• Task.ts: The second content gate at line 3567 (if (hasTextContent || hasToolUses)) is missing hasReasoningContent, so reasoning-only responses still enter the error/retry path and corrupt conversation history
• Task.ts: Reasoning-only responses (no text, no tools) now enter the pWaitFor at line 3584, but presentAssistantMessage is never called when assistantMessageContent is empty, so userMessageContentReady stays false and the task hangs indefinitely

Previous reviews

• 0760818: Review #1
• c51cf58: Review #2

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}