Related Issue

Issue: CLINE-2191 — Widen MessageBuilder truncation candidate set (Layer A)
Stacked on: #10740 — please merge that first.
Sibling follow-up: CLINE-2192 — Absolute hard guarantee (Layer B). This PR does NOT guarantee the request fits.

Description

After #10739 (allowlist) and #10740 (protected-tail trim), the post-compaction preservation set inside the in-flight turn still contains the typed user prompt, the last assistant message, and any in-flight tool_use verbatim. Each can individually exceed any context window. MessageBuilder.buildForApi already has the middle-truncation infrastructure (truncateMiddleByChars, truncateMiddleToBytes, an aggregate-budget pass at truncateToTotalTextBudget). It just doesn't see enough block types and runs against a hardcoded 6 MB cap rather than the model's actual maxInputTokens.

This PR is the preventive layer — the typical over-budget request stops being a 400 and becomes a truncated-but-shipped request. The brick-wall guarantee for adversarial inputs is sibling CLINE-2192, which stacks on top of this one. We are not over-selling: this PR does NOT yet meet the "Ever EVER" bar.

Changes

In sdk/packages/core/src/session/services/message-builder.ts:

1. collectTruncationCandidates widened. In addition to the existing tool_result candidates it now collects user text, assistant text, thinking block text, and top-level file block content. redacted_thinking is skipped (placeholder string). tool_use blocks are skipped — a JSON-aware structural truncator that avoids corrupting tool_use_id or breaking the input JSON shape is Layer B's responsibility.
2. Aggregate budget tied to maxInputTokens. buildForApi(messages, { maxInputTokens }) now derives the cap from the model's actual maxInputTokens (× CHARS_PER_TOKEN = 3). When maxInputTokens is not provided the constructor's hardcoded 6 MB default still applies, so legacy callers behave identically.
3. Deterministic sort. The largest-first sort gains an insertion-order tiebreaker so equal-byte candidates always truncate in the same order. Layer B relies on the same property.

In sdk/packages/core/src/runtime/orchestration/session-runtime-orchestrator.ts:

• createRuntimeHooks and createRuntimePrepareTurn now thread modelInfo.maxInputTokens through prepareMessagesForModelRequest → prepareProviderMessagesForApi → buildForApi. The cap reflects the model that is actually being called, not a 6 MB approximation.

In sdk/packages/shared/src/llms/tokens.ts + index.ts + index.browser.ts:

• CHARS_PER_TOKEN was previously private. Exported alongside the existing estimateTokens.

Test Procedure

Seven new cases in sdk/packages/core/src/session/services/message-builder.test.ts:

1. truncates user text blocks under the aggregate budget (CLINE-2191) — 5 MB user text, 500 KB budget, asserts truncation marker and final size.
2. truncates assistant text and thinking blocks under the aggregate budget (CLINE-2191) — 2 MB text + 1 MB thinking, 250 KB budget, asserts both truncated.
3. truncates top-level file blocks under the aggregate budget (CLINE-2191) — 4 MB file block, 200 KB budget.
4. skips tool_use input bodies (CLINE-2191, deferred to Layer B) — 4 MB tool_use.input.body stays untouched. Doc-test for the deferral.
5. derives the aggregate budget from maxInputTokens when provided (CLINE-2191) — buildForApi(messages, { maxInputTokens: 100_000 }) → 300 000 byte cap.
6. falls back to the constructor default budget when maxInputTokens is absent (CLINE-2191) — legacy callers unchanged.
7. produces deterministic output for equal-byte-length candidates (CLINE-2191) — two equal-byte candidates → byte-identical output across two runs.

Verification:

sdk/packages/core $ bun run typecheck:smoke   # clean
sdk/packages/core $ bun run test:unit -- message-builder.test
  ✓ 16 tests passed (9 existing + 7 new)
sdk/packages/core $ bun run test:unit
  Test Files  102 passed | 1 skipped (103)
       Tests  920 passed | 4 skipped (924)

What this PR still does NOT fix (intentional, deferred to CLINE-2192)

• tool_use.input truncation. JSON-aware structural truncator that drills into string values without corrupting tool_use_id or input shape.
• Adversarial inputs. A pathological transcript of 50k small blocks each below the MIN_TOTAL_BUDGET_TOOL_RESULT_BYTES = 8_000 floor would still overshoot — the largest-first heuristic can't shrink below the floor. Layer B adds the final byte-cap enforcement.
• User-visible status notice and task.emergency_truncation telemetry. Only fires when we enter genuinely degraded mode; Layer B's concern.
• Hard-error path. Policy is "degrade, never error" — neither layer hard-errors.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)

Pre-flight Checklist

• Changes are limited to a single feature, bugfix or chore
• Tests are passing and code is formatted and linted
• I have reviewed contributor guidelines

Additional Notes

The orchestrator threading is a small public-API change (MessageBuilder.buildForApi gains an optional second argument). Existing tests construct MessageBuilder directly without passing maxInputTokens and behave unchanged. The 6 MB hardcoded default stays as the fallback floor so any caller that doesn't yet know about maxInputTokens gets the pre-PR behavior.

Diagram

PR #10747 / CLINE-2191
Layer A: heuristic total text budget in MessageBuilder

Provider messages after per-block truncation:

  text blocks
  file blocks
  tool_result text
  other shrinkable text
        |
        v
  measure total text bytes/chars
        |
        v
  budget = maxInputTokens * 3 chars/token
        |
        v
  over budget?
        |
   +----+----+
   |         |
  no        yes
   |         |
   v         v
 return   choose largest shrinkable blocks first
          middle-truncate them
          skip signed/unshrinkable thinking
              |
              v
          provider payload usually fits