Bug: Microsoft 365 connector uploads .docx files that Microsoft Graph's own conversion pipeline rejects

### What happened?

Summary

`.docx` files written to OneDrive for Business via Claude's Microsoft 365 connector (`sharepoint_upload_file` / equivalent Graph `PUT .../content` write) are not fully OOXML/OPC-compliant. They upload successfully (Graph returns `201 Created`, byte count matches) but are then unopenable almost everywhere except Word's own lenient desktop parser: Word Online refuses to open them, Word desktop errors out with a "check permissions / insufficient memory / try Text Recovery converter" message, and Microsoft Graph's own document-conversion endpoint (`GET .../content?format=pdf`) returns `HTTP 406` with `x-errorcode: OfficeConversion_ContentNotSupported`, `x-errorsource: Content`.

A byte-identical document saved into the same OneDrive folder through the Word client directly opens and converts with no issue, so this is specific to files produced/uploaded through the connector's write path.

## Isolating evidence (rules out tenant policy / Microsoft-side causes)

Ran a controlled A/B test uploading to the exact same OneDrive folder, as the exact same delegated user, via two different Entra-registered apps:

| Uploaded by | Read/converted by | Result |
|---|---|---|
| Claude M365 connector (app `07c030f6-...`) | Claude M365 connector | Blocked (`notSupported`) |
| Claude M365 connector (app `07c030f6-...`) | Microsoft Graph Explorer (independent app, same user) | **Blocked**, identical `OfficeConversion_ContentNotSupported` |
| Microsoft Graph Explorer | Microsoft Graph Explorer | Works |
| Microsoft Graph Explorer | Claude M365 connector | Works |

The failure follows the **uploader**, not the reader — a file the connector uploaded fails no matter who or what tries to read/convert it afterward, and a file any other app uploads (including a plain Graph Explorer `PUT` of a Word-authored `.docx`) works fine no matter who reads it. This rules out Conditional Access, Purview DLP/sensitivity labels, and any other access-control explanation (those would depend on the reader's identity, and would show a permissions-flavored error, not `errorSource: Content`). It also rules out local OneDrive sync/file-lock/path issues on the client Mac, since Word Online and Graph's own server-side conversion pipeline reproduce it with zero client-device involvement. It also rules out unusual characters/encoding in the document body, since a minimal, plain-ASCII test file fails identically to a content-rich one, and the uploaded package is a valid, parseable zip/XML by ordinary tooling — the incompatibility is something more specific to OOXML/OPC compliance that Microsoft's conversion pipeline enforces strictly and Word's own parser does not.

### What did you expect to happen?

## Expected behavior
A `.docx` uploaded via the connector should be indistinguishable, from Microsoft's own tooling's
perspective, from the same document saved through Word — openable in Word Online, convertible via
Graph, and not flagged as `ContentNotSupported`.

### Steps to reproduce

## Steps to reproduce
1. Have Claude (via the Microsoft 365 connector) upload any `.docx` to a OneDrive for Business
folder — either via `sharepoint_upload_file` or by overwriting an existing item with
`sharepoint_update_file`. A trivial, minimal, plain-ASCII `.docx` reproduces it just as reliably
as a large formatted one.
2. Try to open the resulting file:
- Word Online → "Sorry, Word ran into a problem opening this document in a browser. To view this
document please open it in the desktop version of Microsoft Word."
- Word desktop (Mac) → "Word experienced an error trying to open the file. Try these
suggestions: Check the file permissions for the document or drive. Make sure there is
sufficient free memory and disk space. Open the file with the Text Recovery converter."
- Microsoft Graph itself, `GET /drives/{drive-id}/items/{item-id}/content?format=pdf` →
`HTTP 406`, `x-errorcode: OfficeConversion_ContentNotSupported`, `x-errorsource: Content`.
3. Save a `.docx` into the same folder directly from Word (not through the connector) → opens fine
everywhere, including through Graph's own conversion endpoint.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Microsoft 365

### Error messages or logs

```shell
Microsoft Graph document-conversion pipeline (GET .../content?format=pdf):

HTTP/2 406
x-errorcode: OfficeConversion_ContentNotSupported
x-errortype: Expected
x-errorsource: Content
content-type: application/problem+json

Word Online: "Sorry, Word ran into a problem opening this document in a browser. To view this document please open it in the desktop version of Microsoft Word."

Word desktop (Mac): "Word experienced an error trying to open the file. Try these suggestions: Check the file permissions for the document or drive. Make sure there is sufficient free memory and disk space. Open the file with the Text Recovery converter."
```

### Additional context

Environment: Claude / Cowork with the Microsoft 365 connector enabled. Entra enterprise app in the affected tenant: "M365 MCP Server for Claude", app id 07c030f6-5743-41b7-ba00-0a6e85f37c17. Target: OneDrive for Business, personal site. Tenant plan has no Entra ID P1/P2 (Conditional Access unavailable) and no Purview E5/Information Protection & Governance add-on (auto-labeling unavailable) — noted because it rules out policy-based explanations, see isolating evidence above.

Impact: any .docx (and plausibly other Office formats — not separately tested) the connector has ever written to a user's OneDrive/SharePoint may be affected, not just newly-uploaded ones, since the defect appears to be in how the connector constructs/uploads the file rather than anything folder- or session-specific.