Fix DeepSeek reasoning_content propagation

[LMTRADES]

This PR fixes two issues with DeepSeek reasoning_content. 1. Extracts reasoning_content from model_extra for ZenMux responses. 2. Adds empty string fallback for DeepSeek to non-tool-call messages.

[alt-glitch]

Part of the reasoning_content propagation cluster. Related open items: #15748, #15749. See also closed #15250, #15353 for prior fixes in this area.

[LMTRADES]

Hi @alt-glitch! Thanks for linking those.

I reviewed #15748 and #15749, and it looks like there might be a boolean logic bug in the #15749 proposed fix for the cross-provider reasoning leak.

In #15749, if source_msg.get("reasoning") is present (e.g., from MiniMax), has_reasoning evaluates to True. That makes not has_reasoning False, which skips the needs_empty_reasoning block and falls through to the promotion block. This means MiniMax's reasoning still gets promoted to reasoning_content and leaks to DeepSeek.

My PR (#15760) naturally avoids this by evaluating the DeepSeek requirements before the normalized_reasoning promotion block. It injects "" for DeepSeek (for ALL assistant messages, which is another requirement I found) and returns early. This properly stops any stale cross-provider reasoning from leaking into DeepSeek's reasoning_content, while ensuring DeepSeek's own native reasoning is still preserved (since it's caught by the very first explicit_reasoning check).

I've tested this end-to-end and it successfully resolves the 400s without leaking!

[LMTRADES]

Whoops, self-correction! I just took a closer look at the code I pushed originally in this PR and realized it was actually suffering from the exact same ordering issue I just criticized #15749 for.

In my initial push, I had evaluated deepseek_requires_reasoning after the normalized_reasoning check, which meant cross-provider (e.g. MiniMax) reasoning would still have leaked to DeepSeek.

I just force-pushed a fix to this PR. Now the logic works as I described above: deepseek_requires_reasoning and kimi_requires_reasoning are evaluated before the normalized_reasoning check.

This completely strips MiniMax's reasoning and safely injects "" for DeepSeek (or preserves DeepSeek's native reasoning via the very first explicit_reasoning check).

I have confirmed this with test coverage locally. The logic here is now fully water-tight for cross-provider isolation! Thanks for linking the issues and sorry for the initial confusion!

[teknium1]

Closing as redundant — the DeepSeek reasoning_content thinking-mode 400 and cross-provider leak chain of issues is now fully covered on main:

• Direct provider detection + same-provider tool-call pad: commits 93a2d6b, d58b305, ad0ac89, 5ae6081
• All-assistant-messages pad rule: commit ad0ac89
• Ordering / cross-provider isolation: commit 9daa062 + regression guard 63bf7a2
• Cross-provider leak (MiniMax reasoning → DeepSeek): PR fix(agent): block cross-provider reasoning leak to DeepSeek/Kimi (#15748) #16500 (merging shortly)

21 regression tests in tests/run_agent/test_deepseek_reasoning_content_echo.py + 2 new tests for the cross-provider scenario exercise every known path. Thanks for the submission — appreciate the digging on this area.