fix(session): omit unsupported pdf tool-result attachments

[50sotero]

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.

This PR also makes the Windows e2e shortcut assertion deterministic by explicitly blurring the prompt before testing Ctrl+L, because the prior test depended on a blur side effect that is not reliable on Windows CI.

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
• make the existing Windows e2e focus-shortcut test deterministic

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
• inspected the Windows e2e timeout and fixed the test precondition in packages/app/e2e/commands/input-focus.spec.ts

Screenshots / recordings

Not a UI change.

Checklist

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

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

The search results show PR #21917 (the current PR) is the only exact match. However, there are two potentially related PRs that address similar capability mismatch issues:

1. PR fix: guard text-only models from image read attachments #17204 - fix: guard text-only models from image read attachments

   • Related pattern: Guards models from receiving unsupported attachment types (images for text-only models, similar to PDFs for non-PDF-supporting models)

2. PR fix(opencode): handle PDFs in tool results when using Amazon Bedrock #17401 - fix(opencode): handle PDFs in tool results when using Amazon Bedrock

   • Related pattern: Also deals with PDF handling in tool results, though for a different provider context

These PRs address similar architectural concerns about filtering attachments based on model capabilities, though they don't appear to be duplicates of the current PR (which is specifically about omitting PDF attachments when model.capabilities.input.pdf is false).