Kimi OAuth: auto-upgrade `k3` wire model ID from `k3-256k` to `k3` at the 256k context cutoff

[Acters]

Summary:
The Kimi for Coding endpoint now serves K3 under two model IDs: k3-256k (256k context window, cheaper) and k3 (1M context window). The cheaper k3-256k variant is exclusive to the Kimi for Coding OAuth endpoint — the normal pay-per-token Moonshot AI Platform does not expose it — so this applies solely to the kimi-coding-oauth provider. The 1M variant is stated to consume 2× the quota — we cannot verify the exact pricing/quota terms, but this is the stated rationale for why auto-switching is beneficial: 256k of context is still large enough for most tasks, so the first 256k of every session can be served by the cheaper model, and only sessions that genuinely outgrow 256k pay the 1M premium. Per the Kimi backend team, switching from k3-256k to k3 does not invalidate the prompt cache — the cache seamlessly upgrades from 256k to 1M. dreb should expose a single user-selectable k3 model and automatically switch the wire model ID as session context grows, avoiding context compaction on long-horizon tasks.

Current Behavior:
The kimi-coding-oauth provider registers k3 as a single model with a 1M context window. Every request — even a fresh session with a few hundred tokens — is served by the 1M variant at its stated 2× quota rate, despite the cheaper k3-256k variant being available on this endpoint. When context approaches the window limit, auto-compaction is the only mitigation.

Proposed Behavior:

• One user-selectable k3 model. Sessions always start on the cheaper k3-256k wire ID; assistant messages keep recording the registry ID k3.
• When session context passes the 256k cutoff (256k window minus the default compaction reserve, i.e. 245,760 tokens — the point where auto-compaction would trigger under default settings for a 256k-window model), dreb upgrades the wire ID to k3 instead of compacting. No context is lost and the cache continues seamlessly.
• This does not replace auto-compaction: compaction still guards the 1M window. A user who lowers the compaction threshold compacts before the cutoff is reached — including single-response jumps straight past it — effectively disabling the auto-upgrade.
• A context overflow error while in the 256k tier upgrades and retries instead of compacting; an overflow in the 1M tier keeps the existing compact-and-retry recovery.
• The upgrade is model-capability management, not context reduction, so it applies on both the threshold and overflow paths even when compaction.enabled is false.
• The tier is derived, not persisted: session resume re-derives it from the restored context size, and compacted (or otherwise shrunk) sessions return to the cheaper 256k tier. Customizing k3's context window via models.json disables automatic tiering entirely.
• The footer/context usage reflects the effective window (256k → 1M), and a context_window_upgrade session event is emitted (rendered as a status line in interactive mode).

Acceptance Criteria:

• Only one k3 entry is selectable; OAuth discovery never surfaces k3-256k as a separate model.
• A fresh session sends k3-256k on the wire (verified against the live endpoint) and records k3 on assistant messages.
• Crossing 245,760 context tokens upgrades subsequent requests to k3 with no compaction and a context_window_upgrade event.
• With a user-lowered compaction threshold, compaction fires first and no upgrade occurs — also when one response jumps past the cutoff.
• 256k-tier overflow upgrades and retries; 1M-tier overflow still compacts.
• Upgrade occurs even when auto-compaction is disabled (threshold and overflow paths).
• Session resume re-derives the tier from current context size on all entry paths; thinking-effort mapping (incl. xhigh) is unaffected.
• Compacted sessions return to the cheaper 256k tier; a user-overridden k3 context window disables automatic tiering.

Context:

• Follow-up to issue Add Kimi Code k3 and kimi-for-coding-highspeed model IDs to kimi-coding-oauth provider #371 and PR Add Kimi Code OAuth model variants #375 (Kimi Code OAuth model variants).
• Kimi backend team: changing from 256k to 1M does not invalidate cache and seamlessly upgrades cache size from 256k to 1M.
• k3-256k availability is limited to the Kimi for Coding OAuth endpoint; the pay-per-token Moonshot AI Platform has no equivalent cheaper variant.

Technical Notes:

• Implemented in PR Kimi OAuth: auto context tier for k3 (k3-256k → k3 wire upgrade) #416 (fork Acters/dreb, branch feature/issue-415-k3-auto-context-tier, commits 54365f4 + 0fe577e), based on upstream master 23d7ec8. Self-reviewed via mach6 (17 findings → 11 genuine → all fixed and verified; deferrals documented on the PR).
• Adds optional Model.wireModelId; the openai-completions provider sends model.wireModelId ?? model.id in the request payload while recording the registry ID on assistant messages, keeping model identity (selector, thinking checks, session restore, usage tracking) stable.
• New k3-context-tier.ts module derives the effective model from current context tokens; AgentSession applies it on model set/cycle/refresh/restore/creation and upgrades ahead of compaction in _checkCompaction (threshold and overflow paths). Tier matching is hard-scoped to provider === "kimi-coding-oauth" && id === "k3", and a non-stock context window (user override) opts the model out of tiering.
• Out of scope (possible follow-up): the API-key kimi-coding provider (same coding endpoint, Anthropic-compatible) could receive the same treatment. The pay-per-token Moonshot AI Platform is not applicable — it does not expose the cheaper variant.