feat(provider): add none reasoning variant for DeepSeek V4

[huynq55-v3]

Issue for this PR

Closes #N/A

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

DeepSeek V4 exposes a thinking toggle, and its model variants menu currently only surfaced reasoning_effort tiers (low/high/max). This left no way to disable thinking entirely from the variants menu, even though the provider supports reasoning_effort: "none".

This PR adds a none variant alongside DeepSeek V4's existing effort tiers. In packages/opencode/src/provider/transform.ts:1656, reasoningVariants now short-circuits for DeepSeek V4 (deepseek-v4 in the API id) and returns none: { reasoningEffort: "none" } combined with the existing effort variants. Because it only triggers when the target API matches deepseek-v4, behavior for all other providers is unchanged.

How did you verify your code works?

Added a unit test in packages/opencode/test/provider/transform.test.ts asserting that a DeepSeek V4 target with a toggle + effort option produces none, low, high, and max variants, while the rest of the reasoning-variants test suite (Claude extended thinking, etc.) continues to pass.

Screenshots / recordings

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[tanishqvec]

Confirmed your payload works on zen: reasoning_effort: "none" does disable thinking on opencode/deepseek-v4-flash, and zen's validator reports literal['none','minimal','low','medium','high','xhigh','max'], so none is genuinely accepted there.

api.deepseek.com looks different though — its docs list low|high|max for reasoning_effort and disable thinking with {"thinking": {"type": "disabled"}} instead, so sending none to the official provider may not do what we want.

I opened #46181, which patches the same function you did and branches the payload per provider, plus fixes the early return that drops the declared toggle in the first place. You picked the right function — happy to close mine if you'd rather extend yours.

[huynq55-v3]

Thanks for checking and confirming!

Looking at DeepSeek's official documentation, disabling thinking actually depends on the API format being used:

OpenAI format: Uses {"thinking": {"type": "disabled"}} (while effort control uses reasoning_effort: "low/high/max").

Responses API format: Uses {"reasoning": {"effort": "none"}} (none disables thinking directly).

I'm happy to extend this PR to properly handle both payload formats/providers so we have full coverage. Let me know if you'd prefer me to push the updates here!

[huynq55-v3]

Thanks for digging into the root cause and covering the provider-specific payload differences in #46181!

Your PR addresses the underlying early return and handles both Zen and api.deepseek.com cleanly, so I'm closing this one in favor of #46181 to keep things consolidated. Appreciate the thorough follow-up!