V2 read tool does not support PDFs

[rekram1-node]

Problem

The V2 read tool cannot read PDF files. ReadToolFileSystem.read sniffs magic bytes with imageMime(first) only (packages/core/src/tool/read-filesystem.ts:188); a PDF sniffs as non-image, contains null bytes, and fails with BinaryFileError ("Cannot read binary file").

This is a regression from V1, whose read tool returned PDFs as model attachments (packages/opencode/src/tool/read.ts:306 — "PDF read successfully" with a data:application/pdf;base64,... attachment).

V2 is not PDF-blind elsewhere:

• Prompt attachments accept any mime, so users can attach PDFs via SessionV2.prompt.
• Provider lowering already handles application/pdf file parts (e.g. packages/core/src/github-copilot/responses/convert-to-openai-responses-input.ts:104).

The gap is specifically that the agent cannot pull a PDF off disk with the read tool.

Considerations for the fix

• Reuse the existing 20 MiB MAX_MEDIA_INGEST_BYTES cap for PDF ingest, matching image reads and MAX_ATTACHMENT_BYTES.
• Tool settlement currently bounds only image content (ToolRegistry image normalization, feat(core): normalize tool and attachment images at settlement #37141). PDFs have no resize equivalent, so unbounded inline PDF base64 persisted in message rows and re-sent per request would reintroduce the HTTP 413 exposure class (bug(v2): inline image results make compaction fail with HTTP 413 #36552) through a new path. PDF support should land with an explicit size policy for non-image media at settlement (hard cap, drop-with-note, or managed retention) rather than inheriting no bound.
• Model capability varies: only some providers accept PDF input, so the read tool may need to fail gracefully or degrade when the active model cannot consume application/pdf.

[SinghAman21]

hello maintainers. what is the right way to claim an issue and work on it?

[SinghAman21]

The read tool is the easy part. The bigger blocker is that V2 can't actually
send a PDF to most models yet — Anthropic, OpenAI and Gemini all reject
non-image files in tool results, and Bedrock is the only one that works. So
making read return PDFs without fixing that first would just swap today's
"Cannot read binary file" for a worse, request-level error.

On the size policy you mention: there's no size limit on tool result media
today at all, images included. So that'd be new behaviour rather than
inheriting the image bound.

Can I take this one? And do you have a preference on the size limit - reject oversized PDFs outright, or something softer?