#14187: fix: add Moonshot AI to non-standard provider detection

## Problem When using Moonshot AI's direct API (`api.moonshot.ai` / `platform.moonshot.cn`) as a provider, OpenClaw sends the `developer` role in messages. Moonshot's chat completions endpoint enforces a strict role enum (`system`, `user`, `assistant`) and rejects unknown roles with: ``` 400 invalid request: unsupported role ROLE_UNSPECIFIED ``` This makes Moonshot direct unusable as a provider. Fixes #8579 ## Root Cause The `normalizeModelCompat` function in `model-compat.ts` sets `supportsDeveloperRole: false` for providers that don't support the newer OpenAI `developer` role — but only covered Z-AI. Moonshot endpoints were missing from this check, so the `developer` role was sent unmodified and rejected by Moonshot's API. ## Fix Extend the existing Z-AI detection pattern to also match Moonshot endpoints (`moonshot.ai`, `platform.moonshot.cn`, or provider `moonshot`). This ensures `developer` messages are mapped to `system` before being sent. ## Changes - `src/agents/model-compat.ts` — add `isMoonshot` check alongside existing `isZai` - `src/agents/model-compat.test.ts` — add two test cases for Moonshot (provider name and baseUrl detection) ## Testing - Tested locally with `moonshot/kimi-k2.5` via direct API key against `api.moonshot.ai` - Before: `400 invalid request: unsupported role ROLE_UNSPECIFIED` - After: Clean completions with system + user roles accepted - Verified via both raw curl and OpenClaw sub-agent runtime flow <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `src/agents/model-compat.ts` so `normalizeModelCompat` disables the OpenAI `developer` role not only for Z-AI (`api.z.ai` / provider `zai`) but also for Moonshot endpoints (provider `moonshot`, `moonshot.ai`, or `platform.moonshot.cn`). This causes downstream message-role mapping to send `developer` content as `system` for Moonshot OpenAI-completions models. Two unit tests were added in `src/agents/model-compat.test.ts` to cover Moonshot detection via provider name and via base URL. The change is localized and matches the existing Z-AI compatibility behavior. <h3>Confidence Score: 4/5</h3> - This PR looks safe to merge and addresses the reported provider incompatibility with low blast radius. - The change is a narrow extension of an existing compatibility gate: it only affects `openai-completions` models and only when the provider/baseUrl matches Moonshot or Z-AI. Added tests cover both detection paths. I could not execute the test suite in this environment (no node/pnpm), so confidence is slightly reduced. - src/agents/model-compat.ts (provider/baseUrl matching logic) <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->