fix(api): strip MCP image base64 from tool results in the jinja path (#2374)

[Anai-Guo]

Problem

Fixes #2374. When a tool / MCP result carries an image, the OpenAI-compatible chat adapter's jinja code path leaves the base64 payload in the rendered prompt as plain text. As reported, a single 1024×1024 jpeg bloats the context by ~120k tokens. The legacy (non-jinja) path already handles this correctly via strip_mcpcontent_of_media, so the behavior is inconsistent between the two paths.

There are two related gaps:

1. format_jinja never strips the base64 from tool-role string content before rendering, so the whole MCP JSON (including the base64) is templated as text.
2. sweep_media_from_messages only recognizes image_url items inside a content list, not MCP-style image content blocks ({"type": "image", "data": ...}), so images delivered that way are dropped instead of attached.

Fix

• format_jinja: strip the base64 from tool-role string content before rendering (reusing the existing strip_mcpcontent_of_media). The image itself is still swept out and attached separately, so nothing is lost — only the multi-KB base64 stops being rendered as text.
• sweep_media_from_messages: also recognize type == "image" content blocks in a list and attach their data.

Verification

Reproduced both paths with a standalone harness driving the jinja template + sweep logic:

Scenario	Before	After
Tool content = MCP JSON string with an image	prompt rendered 120,209 chars, base64 inline, 1 image attached	prompt 227 chars, no base64 in text, 1 image attached
Tool content = list of MCP image blocks	0 images attached (image dropped)	1 image attached

Change is 7 added lines, no deletions, and mirrors the existing legacy-path behavior.

🤖 Generated with Claude Code