#21911: Enable `reasoning: true` for Kimi models

## Summary When reasoning is on, kimi api returns unsupported role ROLE_UNSPECIFIED because the developer role is not supported, similar to current handling of z.ai models. - Problem: Kimi k2.5 model with `reasoning: true`, mooshot api returns unsupported role ROLE_UNSPECIFIED error - Why it matters: enable thinking mode for kimi models - What changed: not sending unsupported develper role when provider is moonshot api - What did NOT change (scope boundary): ## Change Type (select all) - [x] Bug fix ## Scope (select all touched areas) - [x] Gateway / orchestration ## Linked Issue/PR - Closes #21795 ## User-visible / Behavior Changes None ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: Arch Linux - Runtime/container: - Model/provider: Moonshot Kimi k2.5 - Integration/channel (if any): - Relevant config (redacted): ### Steps 1. in config, set `providers -> moonshot -> models -> reasoning: true` 2. chat thru configured channels ### Expected should allow kimi thinking model to work normally ### Actual api returns unsupported role ROLE_UNSPECIFIED ## Evidence Attach at least one: - [x] Failing test/log before `{"type":"message","id":"b520fafe","parentId":"87885067","timestamp":"2026-02-20T12:34:28.343Z","message":{"role":"assistant","content":[],"api":"openai-completions","provider": "moonshot","model":"kimi-k2.5","usage":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"totalTokens":0,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}}, "stopReason":"error","timestamp":1771590868009,"errorMessage":"400 invalid request: unsupported role ROLE_UNSPECIFIED"}}` - [x] Failing test/log passing after `{"type":"message","id":"53bed4c2","parentId":"614ff8b8","timestamp":"2026-02-20T13:24:09.664Z","message":{"role":"assistant","content":[{"type":"thinking","thinking":"The user sent \"bomb bomb\" in a Discord channel ... that fits the \"Hype-Pa rtner\" role.","thinkingSignature":"reasoning_content"},{"type":"text","text":"💥 **BOOM!** The energy in here just went nuclear! Let's keep this vibe exploding in the best way possible—like confetti cannons, not actual cannons. 🎉\n\nWhat's popping off? I'm ready to hype whatever this is to stratospheric levels!"}],"api":"openai-completions","provid er":"moonshot","model":"kimi-k2-thinking","usage":{"input":495,"output":360,"cacheRead":10752,"cacheWrite":0,"totalTokens":11607,"cost":{"input":0,"output":0,"cacheRead":0,"cac heWrite":0,"total":0}},"stopReason":"stop","timestamp":1771593838782}}`` ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: tested with Kimi k2.5 and k2-thinking models with reasoning enabled/disabled - Edge cases checked: - What you did **not** verify: other models, as I have no access to those ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: just revert the commit - Files/config to restore: - Known bad symptoms reviewers should watch for: ## Risks and Mitigations None <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR extends the existing z.ai developer role compatibility fix to also cover Moonshot (Kimi) models. When `reasoning: true` is enabled for Kimi models, the Moonshot API returns an error for unsupported `ROLE_UNSPECIFIED` because it doesn't support the developer role, similar to the existing z.ai provider behavior. **Key changes:** - Extended `normalizeModelCompat()` to detect Moonshot providers (via `provider === "moonshot"` or `baseUrl.includes("api.moonshot")`) - Forces `supportsDeveloperRole: false` for Moonshot models, preventing developer role messages from being sent to the API - Added test coverage for the Moonshot provider case - Updated existing test description to reflect both providers are now handled <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The changes follow the existing pattern for z.ai provider compatibility, add proper test coverage, and address a real API compatibility issue. The string matching pattern `baseUrl.includes("api.moonshot")` correctly handles both `.ai` and `.cn` domains used by Moonshot. The logic is straightforward and mirrors the existing z.ai implementation. - No files require special attention _{Last reviewed commit: b283439} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->