fix(commandcode): strip thinking suffix from params.model

[naufalmalikr]

Problem

Requests to the CommandCode provider fail with a 403 when the client sends a thinking-level suffix on the model id:

HTTP 403: [commandcode/gpt-5.6-luna(max)] [403]: {"success":false,"error":{"code":"FORBIDDEN","status":403,"message":"Model/provider not recognized: anthropic:gpt-5.6-luna(max)"}}

The upstream /alpha/generate API reads the model from params.model and rejects unknown ids — a gpt-5.6-luna(max) is not a valid upstream model, so the gateway falls back to an anthropic: family guess and 403s.

Root cause

• getModelUpstreamId (providerModels.js) intentionally re-appends the client's thinking suffix (max) so applyThinking can consume it.
• chatCore.js strips the suffix from the top-level translatedBody.model before dispatch.
• But the commandcode translator copies the model into the nested params.model verbatim — the suffix leaks to the wire.

Proof from a real failing request (requestDetails):

"params": { "model": "gpt-5.6-luna(max)" },   // leaked suffix
"model":  "gpt-5.6-luna"                        // stripped (top-level only)

Fix

Strip the thinking suffix when setting params.model in openaiToCommandCodeRequest (reusing stripThinkingSuffix from thinkingUnified.js). The suffix is still consumed by applyThinking for the thinking override; only the wire model is cleaned.

Verified: plain gpt-5.6-luna succeeds upstream; gpt-5.6-luna(max) was the only difference.

Tests

• 3 new unit tests in tests/unit/openai-to-commandcode.test.js (suffix stripped for plain and family-prefixed ids, plain ids untouched).
• npx vitest run unit/openai-to-commandcode.test.js → 14/14 pass.
• Related suites (commandcode-to-openai, thinking-unified, thinking max-clamp, gemini-cursor-commandcode bugs) → no regressions (5 expected fails are pre-existing it.fails).
• npx eslint clean.