Gmail MCP: get_thread returns only text/plain, newsletter HTML bodies are inaccessible

### What happened?

The first-party Gmail MCP connector (`gmailmcp.googleapis.com/mcp/v1`) does not expose the `text/html` part of `multipart/alternative` emails.

The `get_thread` tool offers a `messageFormat` parameter with only two values: `MINIMAL` and `FULL_CONTENT`. For `multipart/alternative` messages, `FULL_CONTENT` returns the `text/plain` part only. The `text/html` part is silently dropped.

For emails delivered via Omeda, Beehiiv, Mailchimp, and similar ESPs — i.e. essentially every marketing newsletter — the `text/plain` part is a boilerplate stub (`"View this email in your browser"`). The actual newsletter content lives in the `text/html` part. Running `get_thread` across multiple issues of the same newsletter returns byte-identical boilerplate each time.

The tool call itself succeeds, so the agent cannot detect the failure. The failure mode is silent and produces a degraded output (e.g. a weekly digest reconstructed from subject lines only) without any error signal.

For comparison, the Microsoft 365 MCP (`microsoft365:mail_get_message`) already exposes a `bodyFormat: text|html` parameter that handles this cleanly. The Gmail REST API (`users.messages.get` with `format=FULL`) also returns the complete MIME tree natively, including every part's `mimeType` and base64url-encoded `body.data`. The data is present at Google's API layer — only the MCP wrapper is stripping it.

### What did you expect to happen?

`get_thread` should return the `text/html` part of `multipart/alternative` messages when the caller requests it.

Proposed fix: add a `bodyFormat` parameter to `get_thread` with values `text|html|raw`, mirroring the pattern the Microsoft 365 MCP already uses.
- Default to `text` to preserve current behavior.
- `html` returns the decoded `text/html` part.
- `raw` returns the full MIME tree (or equivalent structured payload) for callers that need MIME-part selection.

This unblocks the canonical agent use case of reading newsletters, notifications, and receipts — most of which ship as `multipart/alternative` with the meaningful content in `text/html`.

### Steps to reproduce

1. Subscribe a test Gmail inbox to an Omeda- or Beehiiv-delivered newsletter. Payload Daily (`payload@news.payloadspace.com`) is a clean reproducer — free, high-volume, multipart/alternative with an Omeda-generated `text/plain` stub.
2. Wait for at least two issues to arrive (one issue is enough to see the bug, two issues prove the text/plain output is identical across issues).
3. Call the Gmail MCP `get_thread` tool on each message with `messageFormat=FULL_CONTENT`.
4. Observe:
- The returned body is the `text/plain` boilerplate stub, not the article content.
- The returned body text is byte-identical across different issues from the same publisher.
- No error is raised.
5. Cross-check by opening the same messages in Gmail's web UI — the full newsletter content renders correctly, confirming the `text/html` part exists in the message and is simply not being surfaced by the MCP.

Workaround currently in use: web-fetch to the publisher's public archive (e.g. `payloadspace.com`). Works only when public archives exist; fails for paywalled or archive-less newsletters.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Gmail MCP

### Error messages or logs

```shell
HTML Extraction Failed
```

### Additional context

_No response_