fix: keep --effort on the MiniMax API-key request

[hetaoBackend]

Problem

On the API-key path (minimax_api, including minimax routed through minimaxModelSource: minimax_api_key), pi-ai builds output_config: { effort } from the selected effort. patchThinkingPayload then replaces thinking with the openplatform variant and deletes output_config for every provider except a custom provider's xhigh/max. So --effort high|low|… never reached the wire. Captured request bodies for M3.1-Flash with high and low effort both had only thinking: {type: "adaptive"}.

Fix

For minimax_api requests with an explicitly selected effort level, keep output_config.effort (and any other output_config fields) set to the selected value. This mirrors patchManagedThinkingPayload on the managed path. The following are unchanged:

• default: no explicit effort, so nothing is sent and the provider decides;
• plain on/off models such as M3;
• custom providers and other providers.

Tests

New local-turn-payload-transform.test.ts. It resolves a real LocalModelResolver model, runs pi-ai streamSimple with the real payload transform, and captures the request body from fetch:

• M3.1-Flash high/low/xhigh/max on minimax_api puts output_config.effort on the wire, and so does the minimax + API-key source route;
• default and M3 send no output_config.

The new tests fail on main (5/7) and pass with the fix. pnpm typecheck, the capability suite (215 files, 5393 passed) and check:source pass.

Open question

This assumes the open platform's Anthropic-compatible endpoint accepts output_config.effort (the managed gateway already receives it). Please confirm it accepts xhigh and max before merging.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[yujiachen-y]

LGTM