Canonical vocabulary for fit_level/run_mode/runtime: does the CLI adopt the machine codes?

#761 unified the two `fit_to_json` serializers but deliberately left the vocabulary split in place, with a note in the code that it stays "until a future PR deprecates them (see #759)". That PR needs a ruling from you before it can be written, so this is the question rather than the patch.

Today the same four keys carry different value vocabularies depending on which frontend serialized them:

| Key | CLI `fit --json` | REST `/api/v1/models` + MCP |
|---|---|---|
| `fit_level` | `"Perfect"` | `"perfect"` (+ `fit_label: "Perfect"`) |
| `run_mode` | `"GPU"` | `"gpu"` (+ `run_mode_label: "GPU"`) |
| `runtime` | `"llama.cpp"` | `"llamacpp"` (+ `runtime_label: "llama.cpp"`) |
| `capabilities` | `["Tool Use", ...]` | codes (+ `capabilities_label`) |

The CLI values are overlaid on top of the shared serializer in `display.rs` `fit_to_json`, precisely because scripts parse them.

Three ways this can end, and they lead to different work:

1. **CLI adopts the codes** (`fit_level: "perfect"` everywhere), human strings stay available under `*_label`. One vocabulary, `*_label` earns its place. Breaking for anyone matching `"Perfect"` — needs a major bump or a deprecation window.
2. **Dual forever.** The overlay is the contract, `*_label` exists only on the API side, and the divergence is documented as intentional rather than as debt. Zero breakage; the comment in `display.rs` should stop calling it temporary.
3. **Opt-in flag** — something like `llmfit fit --json --codes` — so scripts move when ready and the default never breaks. More surface area, but no forced migration.

I lean 1 with a deprecation window: an agent consuming both surfaces currently has to special-case which one it is talking to, which is the whole reason #759 got filed. But the compatibility cost lands on your users, not mine, so it is your call — and if it is 2, that is a one-line comment fix rather than a PR.

Happy to implement whichever you pick.

Start in display.rs at fit_to_json, then read the compatibility context in #759 and #761 and compare the CLI fit --json values with REST /api/v1/models and MCP output. The issue is not actionable until a maintainer selects one of the three compatibility policies; done would be a documented decision followed by the corresponding implementation or comment change.

由索引模型根据 Issue 内容生成。