Resumed sessions with many images fail with unrecoverable dimension error

When a session accumulates many images (e.g. screenshots pasted during a long coding thread) and is later resumed via the SDK's resume option, the API rejects the request with a 400 error about image dimensions exceeding the limit for many-image requests. The SDK catches this error but surfaces it as the model's response text with no recovery path - particularly in non-interactive (SDK) mode where the only suggestion is "Start a new session with fewer images."

Reproduction:

1. Run a session via the SDK (query() with resume: sessionId)
2. Over the course of the session, accumulate 20+ images in the conversation (screenshots, tool outputs, etc.)
3. Let the session idle until it's evicted
4. Send a new message to trigger a resume

The resume fails with:

An image in the conversation exceeds the dimension limit for many-image requests (2000px). Start a new session with fewer images.

Why it works live but fails on resume:

During a live session, the same images are accepted by the API on every turn. On resume, the entire conversation is reconstructed from the JSONL and sent to the API in one shot. The API applies a stricter per-image dimension limit (2000px) in the "many-image" regime. The images are individually under 2000px (e.g. 850x1100), but sending them all at once triggers the rejection that never happened during incremental turn-by-turn ingestion.

Expected behavior:

The SDK already has the full message history in the JSONL. On resume, it could replay the conversation incrementally - feeding messages to the API one by one the same way they were originally ingested. If the API accepted each turn during the live session, it should accept the same sequence during restore. This would avoid the many-image regime entirely.

Workaround:

I wrote a workaround that detects this error, strips the oldest image from the session JSONL, and retries. It peels one image per attempt until the API accepts. This confirms the session is otherwise valid - only the bulk image submission is the problem.