[Bug]: kimi-coding/k3 answers HTTP 500 server_error on every request of a fresh session (Kimi For Coding subscription)

## Report

Discord (omo community, 2026-09-09 01:11-01:22 KST), OmO Native (omo-senpi) with senpi 2026.9.7-2, model `kimi-coding/k3` at effort `max` (footer `k3:max`), authenticated through the Kimi For Coding subscription login (`kimi.com`): a **fresh** session (footer `174/1M`) answering `hi` fails on every attempt:

```
Error: 500 {"error":{"message":"The server had an error while processing your request","type":"server_error"}}
Error: 500 {"error":{"message":"The server had an error while processing your request","type":"server_error"}}
Error: 500 {"error":{"message":"The server had an error while processing your request","type":"server_error"}}
⠇ Retrying (3/9) in 3s... (esc to cancel)
```

Reporter: "언제부터인가 kimi-coding/k3 안댐, 500에러가 남, 분명히 kimi.com 에서 인증 한것임" (stopped working at some point; definitely logged in at kimi.com). The model list shows `k3 [kimi-coding]`, `k3-256k [kimi-coding]`, `kimi-k3 [moonshotai]`, `kimi-k3 [moonshotai-cn]`.

## What is known so far

- `kimi-coding` = `anthropic-messages` api against `https://api.kimi.com/coding` (`packages/ai/src/providers/kimi-coding.ts`), retry profile `KIMI_CODE_RETRY_PROFILE` (turn stage 9 retries - matches `Retrying (3/9)`).
- Catalog for `k3`: `forceAdaptiveThinking`, `thinkingLevelMap` low/high/max, `contextWindow` 1048576 (`packages/ai/src/providers/data/kimi-coding.json`); adaptive thinking for Kimi Coding dates from 2026-07-16 (b8575f60f) and worked then.
- The failing request is the **first** request of a fresh session, so this is not the replayed-history 500 documented by other clients (charmbracelet/crush#2263 fails on turn 2). Kimi's own error reference classifies HTTP 500 as server-side, but their Anthropic-compatible layer is known to answer 500 rather than 400 for request shapes it cannot parse.
- `packages/ai/src/api/anthropic-messages.ts` (shared with this provider) changed on 2026-09-08: 8a3902dc9 (mid-output fallback boundaries), 13a944481 (tool-reference pass moved into a module), 8d21e12a1 (provider HTTP status delivery), ce7d4b8a9 (gateway-namespaced tool references folded onto tools). Whether any of these changed the bytes sent to `api.kimi.com` for k3 is the open question.
- No Kimi For Coding credential is available on the maintainers' machines, so the request could not yet be replayed live.

## Diagnosis plan (in progress)

1. Capture the exact request senpi sends for `kimi-coding/k3` (effort max, fresh session, omo-native toolset) through a local interceptor (agent-dir `models.json` baseUrl override) that answers the same 500 body.
2. Diff it against the MoonshotAI kimi-cli/kosong reference client and the Kimi Code docs; list every field the Kimi Anthropic-protocol endpoint is not documented to accept (adaptive `thinking`, `output_config.effort`, `anthropic-beta`, `cache_control`, `metadata`, tool schemas).
3. Bisect live with a Kimi For Coding credential (drop one field per attempt) and fix the client-side trigger, or record the 500 as server-side with a dated capture.

**If you hit this too**: please attach the `--log-level debug` / session JSONL request capture (redact `Authorization`), the senpi/omo version, and whether `k3-256k` or effort `high` behaves differently - that shortens step 3 considerably.

Start with packages/ai/src/providers/kimi-coding.ts and packages/ai/src/api/anthropic-messages.ts, then inspect the k3 entry in packages/ai/src/providers/data/kimi-coding.json. Capture a fresh request using the agent-dir models.json baseUrl override and compare it with the Kimi reference client and docs. Done means isolating the request field that triggers HTTP 500 and fixing it, or recording the failure as server-side with a dated capture.

Written by the indexing model from the issue text.