fix(models): publish effort_tiers on Kimi K3 base models only

[gonisulaimann]

Summary

GET /v1/models wasn't advertising Kimi K3's reasoning tiers (low/high/max) on the kmca base entries (k3, k3-256k), even though the synced metadata carries supportedThinkingEfforts: ["low", "high", "max"]. Catalog-only clients (OpenCode, plain SDK pickers) had no tiers to copy and invented incorrect values.

Why: effectiveEffortTiers() in syncedCapabilities.ts bails out as soon as isSkippedEffortProvider(ownedBy) is true — which covers every codex/glm/kimi-owned model — so the tiers never reached the base entries. That gate exists to stop synthetic <id>-<tier> variant generation in shouldExposeSyncedEffortVariants (still intact), not to hide tiers from the base model.

The fix is model-scoped: the codex/glm/glm-cn/glmt + non-K3 kimi exclusion is restored exactly as before, and only Kimi K3 base entries on kimi-owned providers (k3, k3-256k, incl. kmca/k3) are exempted so their tiers publish. Codex/GLM behavior is unchanged by this PR.

Related Issues

• Closes fix(api): GET /v1/models hides Kimi K3 effort_tiers (low/high/max) #12299

Validation

• Change type: provider (models catalog)
• Focused tests and category gates from the golden path (24/24 on the two files below)
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward (rebased onto release/v3.8.51)
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/kimi-k3-effort-tiers-12299.test.ts (new) — 6 tests: K3/K3-256k base entries publish effort_tiers, merge path, synthetic-variant prevention, registry shape.
• tests/unit/synced-capabilities-learned-effort-override.test.ts (12 tests restored) — back to asserting codex/glm/glm-cn/glmt and non-K3 kimi models never receive effort_tiers.

Coverage Notes

• The logic change lives in src/app/api/v1/models/syncedCapabilities.ts; both new files exercise the exemption and the exclusion paths.

Reviewer Notes

• The carve-out matches the k3/k3-256k (incl. kmca/k3) pattern the executor/translator layers already use; everything else keeps the feat(providers): capture upstream reasoning.supported_efforts at sync so synced openai-compatible models become selectable with effort levels #7694 exclusion.
• Changelog: single fragment 12371-kimi-k3-effort-tiers.md referencing fix(api): GET /v1/models hides Kimi K3 effort_tiers (low/high/max) #12299.

[diegosouzapw]

Thanks for covering the Kimi K3 catalog gap. The Kimi-specific behavior is proven by the focused tests, and the full focused set passed 47/47 in a synthetic merge.

Please address these items before we approve the fork workflows:

1. Keep exactly one changelog fragment. Remove changelog.d/fixes/0000-kimi-k3-effort-tiers.md, retain the numbered fragment, and fix its malformed nested issue/PR link.
2. Keep this PR scoped to Kimi unless you add explicit downstream proof for Codex and GLM. The issue only requires Kimi, while the current diff also reverses the existing Codex/GLM exclusion contract.
3. The OpenCode plugin maps every server-declared capabilities.effort_tiers blindly into variants and its tests explicitly say eligibility is gated server-side. Publishing tiers for Codex/GLM therefore needs provider-specific plugin regression coverage showing that it does not duplicate or conflict with their native suffix mechanisms. The safer recommendation is to preserve the Codex/GLM guard and allow the Kimi base entries only.
4. Update the PR body and tests to match the final, bounded scope.

After the head is updated, I will approve the fork-triggered workflows and revalidate the exact candidate on the current release tip.

[gonisulaimann]

Thanks for the detailed review. All four points are addressed in the updated head (7cc44c2) — the PR now only touches 4 files:

1. Changelog — 0000-kimi-k3-effort-tiers.md is gone; 12371-kimi-k3-effort-tiers.md is the only fragment left, its nested issue/PR link is fixed, and the text now describes the narrowed Kimi-only scope.

2. Scope — the isSkippedEffortProvider gate is restored in effectiveEffortTiers(). The only exemption left is model-scoped: kimi-owned providers whose model id is in the K3 family (k3, k3-256k, incl. prefixed forms like kmca/k3 — the same pattern the executor/translator layers use). Codex, GLM, GLM-CN, GLMT and non-K3 Kimi models keep the exact feat(providers): capture upstream reasoning.supported_efforts at sync so synced openai-compatible models become selectable with effort levels #7694 exclusion, and shouldExposeSyncedEffortVariants is untouched.

3. Codex/GLM guard — per your recommendation, no Codex/GLM base models publish effort_tiers; only the Kimi base entries do.

4. PR body + tests — the description and title now state "effort_tiers on Kimi K3 base models only; Codex/GLM exclusion unchanged". The 12 tests that were flipped in synced-capabilities-learned-effort-override.test.ts are reverted to asserting codex/glm/glm-cn/glmt and non-K3 kimi models never get effort_tiers (incl. the merge-path exclusion); kimi-k3-effort-tiers-12299.test.ts is the one asserting Kimi K3 now receives them.

Ran the specs on the updated head: 24/24 on the two focused files, 54/54 on the related effort-tier suites, and typecheck/lint are clean.

[gonisulaimann]

Rebased the branch onto the current release/v3.8.51 (910f58c5) — it had drifted ~120 commits behind upstream. The change itself is untouched: still Kimi K3 base models only, Codex/GLM keep their exclusion, and the changelog fragment is unchanged. Same 4 files as the previous head.

Re-ran the focused specs on the rebased head to be safe: kimi-k3-effort-tiers-12299 (6/6) and synced-capabilities-learned-effort-override (18/18), plus the neighbouring effort-tier suites (90 tests) — all green. Typecheck, ESLint and Prettier are clean too.