Reading PDF attachments from Outlook fails

Here's the new bug report — your in-chat diagnostics gave this one a lot of solid evidence, so I structured it accordingly:

Title: Reading PDF attachments from Outlook fails at the base64 handoff to the reader (all tested models)

Summary: Reading a PDF attachment (13.9 kb) from an Outlook email fails consistently. The attachment downloads successfully — returned as ~27 KB of inline base64 into the conversation context — but the model turn immediately after fails with a generic "model is not responding" error before the PDF reader is ever invoked. The failure is payload/pipeline-driven, not model-specific: it reproduces on GLM 5.3 Flash, DeepSeek V4 Flash, and DeepSeek V4.1 Flash, in both a custom AI Assistant (SAP B1 + Outlook connected) and a plain new chat with only Outlook. Uploading the same PDF directly into the chat works fine, so the reader itself is functional - the failure sits specifically in the handoff from the Outlook attachment download to the reader.

Steps to Reproduce:

Connect Outlook to the chat (reproduced in a custom AI Assistant with SAP B1 + Outlook, and in a plain new chat with only Outlook).
Ask the model to read a PDF attachment from an inbox email.
Observe the failure. Repeat with different models - same result each time.

Actual Result:

Email search, opening the message, listing attachments, and downloading the attachment all succeed.
The download returns the full PDF as ~27,000 characters of inline base64.
The very next model turn fails with a generic error, e.g.:
- "GLM 5.3 Flash - EU" is not responding right now. Try again later. If this keeps happening, contact your administrator.
- "DeepSeek V4.1 Flash - EU" is not responding right now. Choose another model below or try again later.
The PDF reader (read_attachment) is never reached.
Uploading the same PDF directly into the chat succeeds — confirming the reader works and isolating the failure to the Outlook attachment path.
The conversation continues normally after the failure, so the payload sitting in history alone does not break subsequent calls — the failure is tied to that specific processing turn.

Expected Result:

A PDF attachment fetched from Outlook should be readable end-to-end, regardless of model.

Suspected root cause (from in-chat diagnostics): The next model response must re-emit the full ~27 KB base64 payload as a tool argument, since read_attachment requires the base64 string as a parameter. Possible mechanisms:

Tool-result or request size limit exceeded → request rejected
Handoff bug converting inline base64 into a file handle / model-consumable part
Tokenization blowup from long unbroken base64 strings
Provider rejects the request shape (e.g., document part sent to a text-only model)

Suggested fix direction: Pass a file handle (e.g., copilot-file://) to the reader instead of raw base64 bytes, so the model never has to echo the payload back as a tool argument.

Notes for devs:

The error message is misleading: it names the selected model, but cross-model testing shows the cause is in the request/pipeline, not the model.
Worth checking backend logs for the real error behind the generic message at that turn; max tool-result size; and how inline base64 from app tools is handled vs. file handles.
Isolation test available: a tiny attachment vs. this one would separate size from format as the trigger.