Issue for this PR

Closes #21908

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

This PR stops completed tool results from forwarding PDF attachments back into model context when the selected model does not support input.pdf.

read.ts currently treats PDFs as attachments and returns PDF read successfully, which is fine. The problem is later in MessageV2.toModelMessagesEffect(): completed tool-result attachments are passed through for OpenAI-compatible SDKs without checking whether the actual model can accept PDFs. That means a healthy PDF can be reintroduced into model context for a model that cannot consume PDFs, and the downstream provider/model can respond as if the file were malformed.

Important context: the investigated session used the Oh My OpenAgent plugin. The repeated continuation / todo spam observed in that session should be treated as plugin-influenced behavior, not as the primary OpenCode-core bug this PR is fixing. This PR is intentionally limited to the PDF capability mismatch in core message assembly.

The change is intentionally narrow:

• keep the existing behavior for models that support PDF input
• drop only application/pdf tool-result attachments when model.capabilities.input.pdf is false
• add a regression for the read tool-result case

How did you verify your code works?

• confirmed the failing PDF from the investigated session is healthy (%PDF-1.4, SHA-256 5ba26ba22bca394c29ab50d8ac1ba4097332a1100d76d9b1e2aae4195cc6216b)
• traced the upstream code path from tool/read.ts into session/message-v2.ts
• added a targeted regression in packages/opencode/test/session/message-v2.test.ts
• reviewed the exact CI failure for the first PR revision and corrected the test expectation to match the actual serialized tool-result shape

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR