fix(sse): clamp max_tokens to the model output cap on every path

[diegosouzapw]

Problem

A client-supplied max_tokens above the target model's own output ceiling reached the
upstream unchanged on the single-model path, where it can come back as
"response exceeded output token maximum".

Two clamps existed, neither covering the case:

• enforceOutputTokenBudget() (open-sse/handlers/chatCore/outputTokenBudget.ts) capped the
  three output-token fields, but only against the remaining context window
  (contextLimit − estimatedInputTokens) — not against the model's output cap.
• resolveReasoningBufferedMaxTokens() (open-sse/services/reasoningTokenBuffer.ts:42) does
  clamp to getExplicitModelOutputCap(), but only for supportsThinking models and only
  inside combo routing.

So a plain (non-combo) request to a non-thinking model was never bounded by the model's own
ceiling. This becomes reachable as soon as an operator raises the global output budget above
some routed model's cap — e.g. Claude Code with CLAUDE_CODE_MAX_OUTPUT_TOKENS=128000 in
front of a 64K-output model.

Change

enforceOutputTokenBudget() takes an optional fifth argument, the model's output cap, and
uses it as an additional upper bound when adjusting the fields only:

effectiveCap = cap != null && cap > 0 ? Math.min(availableOutputTokens, cap) : availableOutputTokens

The accept/reject decision (ok:false) and the returned availableOutputTokens stay tied to
the context window alone. That separation is deliberate: a model whose output ceiling is
smaller than defaultOutputTokens must not start returning 400. The cap limits how much is
requested, never whether the request fits. A dedicated test guards this.

The callsite (open-sse/handlers/chatCore.ts) resolves the cap with
getExplicitModelOutputCap({ provider, model: effectiveModel }) — the object form, matching
the sibling capability lookups in the same file. The bare-string form resolves to
provider: null, which skips both the registry cap and the operator's max_token capability
override (#6524); clamping against a stale static spec while the operator had raised the
ceiling would silently truncate output.

Properties: only ever reduces, never raises. Absent / null / non-positive cap (unknown model)
leaves behavior byte-identical — fail-open. Idempotent with the reasoning buffer, which already
lands at or below the same ceiling.

Tests

• tests/unit/output-token-budget-model-cap.test.ts (8) — clamp above the cap; no elevation
  below it; cap absent ⇒ identical result; all three field names; window tighter than the cap
  wins; cap smaller than defaultOutputTokens still accepted (the 400 regression guard);
  adjustedFields exactness; sub-token cap treated as absent.
• tests/unit/chatcore-model-output-cap-wiring.test.ts (2) — drives handleChatCore() end to
  end against a stubbed fetch and asserts the body actually dispatched upstream. The cap
  arrives via an operator max_token override, so the test pins the { provider, model }
  keying too. Verified to fail when the cap argument is dropped and when the lookup is
  switched to the bare-string form.

Existing suites pass unedited: output-token-budget.test.ts,
chatcore-combo-context-limit-8378.test.ts, chatcore-context-window-boundary.test.ts,
reasoning-token-buffer-6274.test.ts. typecheck:core and lint clean.

Known remaining gap (not in this PR)

When the client sends no max_tokens and the target is Claude format,
open-sse/translator/helpers/maxTokensHelper.ts injects DEFAULT_MAX_TOKENS (64000) after
this clamp, unbounded by the model cap. adjustMaxTokens() is model-agnostic and called from
several translators, so bounding it means threading the cap through them — a wider change than
this fix. Filed as follow-up rather than smuggled in here.