Add support for Kimi-Code

[tingles2233]

Add support for Kimi-code please if possible. Especially now with K3 out...

[ozymandiashh]

Taking this one. Good news versus the usual new-provider flow: I have a live Kimi Code CLI install (0.27.0) with real sessions generated locally, so the provider is being built against a verified store schema from day one, not reverse engineering.

What the store looks like (verified on disk): ~/.kimi-code/sessions/wd_<project>_<hash>/session_<uuid>/ with a state.json (title, workDir, agents map) and per-agent agents/<id>/wire.jsonl event streams. Per-turn usage comes from usage.record events (inputOther, output, inputCacheRead, inputCacheCreation), the real model id (e.g. kimi-k3) lives on llm.request events (the usage.record.model field is the config alias, a trap worth knowing about), there are no cost fields so cost is computed from tokens (kimi-k3 pricing is already in the fallback since #709), and failed sessions leave retry-only streams with no usage records. Subagents get their own wire.jsonl, and multi-turn continuations append to the same stream.

Note for scoping: kimi-cli (the predecessor) is being wound down and Kimi Code CLI migrates its config and sessions on install, so this provider targets the ~/.kimi-code store only.

PR to follow shortly with sanitized fixtures for all the observed shapes (success, multi-tool, multi-turn, retry-only, subagent, malformed lines).

[ozymandiashh]

PR is up: #750. Built and validated against a real local Kimi Code CLI store (details in the PR body), fixture-based tests for every observed session shape, hardened after an adversarial multi-model review. @tingles2233 if you have real kimi-k3 usage in ~/.kimi-code, giving the branch a spin and confirming your numbers look right would be a great extra data point before merge.