fix: DeepSeek V4 compatibility in thinking mode

[Denis-666]

English

This PR fixes DeepSeek V4 compatibility in thinking mode.

• Preserve reasoning_content for DeepSeek assistant messages with tool calls.
• Reattach reasoning when streaming splits thinking, text, and tool-call blocks across assistant messages with the same message id.
• Keep the required thinking block when resuming DeepSeek tool-call conversations.
• Add a fallback for old local transcripts that already lost the original reasoning content.
• Add DeepSeek V4 as a visible first-run/provider setup option with deepseek-v4-pro?reasoning=xhigh defaults.

Validation:

• npx --yes bun@1.3.11 test src/services/api/openaiShim.test.ts src/utils/conversationRecovery.hooks.test.ts --timeout 20000

No real API keys are included.

中文

这个 PR 修复 DeepSeek V4 thinking mode 的兼容性问题。

• 为 DeepSeek 的 assistant tool-call 历史保留 reasoning_content。
• 当 streaming 把 thinking、text、tool call 拆成同一个 message id 的多个 assistant message 时，重新挂回 reasoning。
• 恢复会话时保留 DeepSeek tool-call 后续请求需要的 thinking block。
• 对已经丢失原始 reasoning 内容的旧本地会话增加兜底。
• 在首次安装和 provider 配置里加入可见的 DeepSeek V4 选项，默认使用 deepseek-v4-pro?reasoning=xhigh。

验证：

• npx --yes bun@1.3.11 test src/services/api/openaiShim.test.ts src/utils/conversationRecovery.hooks.test.ts --timeout 20000

没有包含真实 API key。

[Denis-666]

This PR is ready for review. The merge is currently blocked by the repository protection rule requiring approval from someone other than the last pusher, and code quality results are still pending. Could a maintainer please review / approve / trigger the checks when convenient? Thanks.

[jatmn]

#910 would be bocker for this at the moment.

[gnanam1990]

Nice work — reasoning_content preservation across split assistant chunks is the right approach, and the recovery fallback for older transcripts is a good touch. Regression tests are present.

Heads up: this overlaps with #918 in openaiShim.convertMessages. Suggest letting the smaller #918 land first and rebasing this on top to keep the diff focused. Approving as-is; happy either way on merge order.

[Denis-666]

Thanks for the review. I can rebase this PR after #918 lands if that keeps the diff easier to merge. Please let me know whether you prefer waiting for #918/#910 or merging this as-is.

[jatmn]

#910 touches openaiShim a lot.
probably after that one.

[kevincodex1]

looks good to me

[kevincodex1]

Hello @Denis-666 kindly rebase to main and fix conflicts we have a major change in provider onboarding and it affects a lot files.