fix(runtime): don't count image bytes as raw chars in the context-budget verdict

[liuxiaocs7]

Summary

A first-turn message carrying a single user-uploaded image can fail immediately with context_budget_exhausted / no_safe_completed_span — the runtime record shows Steps (0), ~263 ms, no provider round-trip. The turn is killed before anything is sent.

Root cause: the mid-turn final-request capacity verdict sized the outgoing payload with JSON.stringify(messages).length. That serializes an inline image at the size of its transported bytes — a Uint8Array/Buffer expands to a digit map ({"0":..}, or {"type":"Buffer","data":[...]} once JSON.stringify applies Buffer.toJSON), and a base64 image is counted at full length. Divided by charsPerToken a single ~150 KB screenshot reads as hundreds of thousands of "tokens", exceeding the window on its own. It surfaces most on a model with no known context window: resolveContextBudgetCapacity returns policy_fallback (48,384 tokens), and policy_fallback is exactly the case where the verdict runs on step 0, before the first request. Being the first turn, the current user message is the pinned head anchor and nothing is foldable, so the verdict resolves to no_safe_completed_span. The reported Desktop path reads a session-file upload as a Node Buffer (packages/storage/src/artifact-attachments.ts), so the estimate must survive Buffer.toJSON.

The fix walks the ModelMessage content and discounts only genuine images to a bounded per-image estimate (~1.6K tokens, the vision per-image ceiling) scaled by the policy's charsPerToken. Image classification mirrors the AI SDK's own normalization (convert-to-language-model-prompt), so the estimate matches what the provider is billed: an image part, an image top-level mediaType (bare image or image/*, including a data: URL's own type), or inline bytes whose signature is a known image (the SDK overrides the declared mediaType from the byte signature). Each image is charged once regardless of how it is carried (inline bytes, a data: URL, or a remote reference); only inline bytes are stripped from the serialized size, and a remote http(s) URL stays verbatim. Everything else is left to serialize verbatim:

• Non-image files (PDF, text, audio, …) stay fully measured — the budget must not silently under-count content the provider really bills.
• Look-alike content (e.g. an arbitrary { type: 'data' } tool-call input) is untouched.

This removes the over-count without reintroducing the opposite image-counts-as-zero under-count fixed in #3372. All four capacity call sites share the one function, so they stay consistent.

Fixes #4290

Verification

• Estimator unit tests (mid-turn-image-payload-chars.test.ts, 13/13): the Buffer / Uint8Array / base64 / data: URL / remote-URL-string / bare-image-type / generic-MIME-with-magic-bytes / PDF / tool-call-input shapes, charsPerToken scaling, and no change for text-only messages.
• End-to-end backend test (mid-turn-capacity-backend.test.ts): an unknown-window model, a first turn whose only message is a 200 KB Buffer image upload — the provider now receives the request (with the image materialized) instead of a pre-send context_budget_exhausted. The fixture's attachment reader was made to return a Node Buffer, matching production.
• No regressions in the adjacent suites, run locally: context-budget-mid-turn-policy (8), mid-turn-capacity-backend (67), overflow-reactive-recovery (43), ai-sdk-backend (217), history-compaction (22).
• tsc -p packages/runtime/tsconfig.json clean; biome check clean on the changed files.

Review focus

The policy_fallback fail-open (letting the provider's real token count decide for a first, unshrinkable user message) is intentionally not in this PR — it would change the verdict for large first-turn text, files, and tool schemas, and belongs in its own issue/PR with reactive-recovery coverage.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Anthropic) performed the root-cause diagnosis, wrote the runtime fix in ai-sdk-compaction.ts, and authored the regression tests. The commit carries a Generated-by trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[liuxiaocs7]

Closing as superseded.

Current main already fixes the underlying issue this PR targets (#4290 — the mid-turn context-budget verdict counting inline image bytes as raw chars), via #4486 ("let the provider decide fit, anchor estimates on real usage, retire the local verdict"). That change reworked midTurnRequestPayloadChars to bill an image at MATERIALIZED_IMAGE_TOKENS * charsPerToken instead of its serialized byte length (using isInlineImageFilePart), and reworked the surrounding capacity verdict and the call sites this PR touches.

Rebasing this branch onto main produces a competing duplicate of a function main has already rewritten, so there is nothing left to merge. The common case from #4290 — a Desktop-uploaded image carried as inline image/* bytes — is handled upstream.

The only coverage this PR adds beyond main is a few edge cases isInlineImageFilePart does not classify as images: generic-MIME payloads identified by magic bytes, a bare image mediaType, the image content-part type, and data: URL images. If any of those matters in practice, it is cleaner to add as a small enhancement on top of main's isInlineImageFilePart in a fresh PR.

Thanks!