feat: implement reasoning content passback for chat completions

[chenyme]

Summary

Fix DeepSeek OpenAI-compatible tool-call follow-up failures in thinking mode.

DeepSeek Chat Completions may return reasoning_content together with tool calls, and requires that reasoning_content be passed back in the next API request. The conversation tool loop previously only preserved visible assistant content, so DeepSeek tool follow-up requests could fail with reasoning_content in the thinking mode must be passed back to the API.

This change adds a route capability for reasoning_content passback, stores streamed reasoning content, and includes it only for DeepSeek Chat Completions assistant tool-call messages.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd backend && go test ./internal/application/channel
• cd backend && go test ./internal/application/conversation
• cd backend && go test ./internal/infra/llm
• cd backend && go test ./...
• git diff --check

Screenshots, API examples, or logs

Before fix, DeepSeek tool follow-up requests could fail with:

HTTP 400, Error from provider (DeepSeek): The `reasoning_content` in the thinking mode must be passed back to the API.

Configuration, migration, and compatibility notes

No config changes, database migrations, or deployment changes are required.

The new reasoning_content passback is scoped to DeepSeek routes using the OpenAI Chat Completions protocol. Other providers and protocols keep their existing request behavior.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.