Many-image dimension rejection in long sessions despite client-side resize

The Error

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

This surfaces as a 400 from the API with image dimensions exceed + many-image in the error body. It hits users in longer sessions that accumulate images organically (screenshots, file reads, bash output, MCP tool results) -- none of which were oversized individually.

Root Cause

• The client resizes all images to max 2000px on ingest
• The API internally resizes at 1568px for normal requests
• But for "many-image" requests, the API enforces a hard reject instead of silently resizing
• Images that were fine when added become poison as the conversation grows
• The existing excess-media stripping caps count (at 100) but never re-checks dimensions
• The recovery path strips images entirely rather than downsizing, and only attempts once

Proposed Fix: Two-Tier Resize

Add a downsample pass in the API call pipeline, right next to the existing media-count stripping:

1. Count media items in the outbound request (this count is already available)
2. If count exceeds a threshold (whatever the API considers "many-image"), walk all image blocks and re-resize any with dimensions > 1568px down to 1568px
3. This happens at API call time, so it's transparent -- images stay at 2000px in local state, only get downsized in the wire payload

Why This Over Alternatives

| Alternative | Problem |
|---|---|
| Lower default to 1568px globally | Loses quality for 1-4 image requests for no reason |
| Rely on the existing recovery path | Only tries once, strips images entirely instead of downsizing, loses context |
| Lower to 1568px at ingest time | Same quality loss; can't know at ingest how many images the request will eventually have |
| Strip oldest images more aggressively | Loses information unnecessarily when downsizing would suffice |

The two-tier approach preserves max quality when possible and only downsizes at the wire level when the request actually enters many-image territory. The original 2000px buffers stay in conversation state, so if images get compacted away and the count drops, surviving images return to full resolution on the next turn.