MCP EmbeddedResource with non-image mimeType (text/csv) incorrectly routed through image pipeline — "The tool returned an image in an unsupported format"

## Summary

An MCP tool returns a `CallToolResult` containing an `EmbeddedResource` / `BlobResourceContents` with `mimeType: "text/csv"` (a CSV report file, base64-encoded). On claude.ai (web chat), this causes the error:

```
The tool returned an image in an unsupported format.
```

This is **not** a case of an unsupported *image* format (e.g. SVG) — the resource is not an image at all. The `mimeType` is correctly declared as `text/csv` in the MCP server source code (verified directly against the implementation).

## Server-side code (verified correct)

```java
BlobResourceContents blob = new BlobResourceContents(
"report_" + plannerId + ".csv", "text/csv", base64Csv
);
return CallToolResult.builder()
.addTextContent(toJson(m))
.addContent(new EmbeddedResource(null, blob))
.build();
```

## Observed behavior

- On **claude.ai (web chat)**: the tool call fails with "The tool returned an image in an unsupported format."
- On **Claude Code / Claude Desktop with a local MCP proxy**: the same tool call succeeds — the resource is correctly saved to disk as `text/csv`, no rendering attempted.

## Hypothesis

The claude.ai client-side resource→content-block mapping appears to route `EmbeddedResource`/blob content into an image-rendering path by default, regardless of the declared `mimeType`, rather than respecting `text/csv` (or falling back to a generic file/download presentation).

## Why this matters

This blocks any MCP tool that returns non-trivial file attachments (reports, exports, CSVs, PDFs, etc.) as MCP resources when used from claude.ai web chat — not a narrow set of unsupported image formats.

## Prior art / confirms client-side root cause

[sooperset/mcp-atlassian#1419](https://github.com/sooperset/mcp-atlassian/issues/1419) reports the exact same error string for a completely unrelated MCP server (Jira attachment download, `.zip` binary). The reporter there explicitly confirms: *"The error string does not appear anywhere in the mcp-atlassian source, so it originates host-side: the MCP client (Claude)."* A same-repo workaround PR exists ([#1424](https://github.com/sooperset/mcp-atlassian/pull/1424), returning attachments as `TextContent` instead of a blob), but that is not viable for larger files like ours.

## Related but distinct issue

[anthropics/claude-code#15807](https://github.com/anthropics/claude-code/issues/15807) — auto-closed as stale, no confirmed fix — describes actual unsupported *image* formats (e.g. SVG). This report describes a **non-image resource being misrouted into the image pipeline**, which appears to be a different (or shared) root cause worth tracking separately since #15807 was closed without resolution.