Gmail MCP: message bodies are quoted-printable decoded twice, silently corrupting URLs

### What happened?

Message bodies appear to be quoted-printable decoded twice. The second decode runs over already-decoded text and eats any = followed by two valid hex characters, replacing all three with the byte they denote.

Any HTML email with the standard X-UA-Compatible meta tag shows it, since the correct input is known:

```
sent: content="IE=edge"
returned: content="IEge"
```

`=ed` became byte `0xED`, invalid standalone UTF-8, so it became `U+FFFD`.

The same thing happens to every URL in the message:

```
sent: ?campaign_id=247164&session_recipient_id=152313356&signature=v2%3Alegacy%3A
returned: ?campaign_id$7164&session_recipient_id2313356&signature=v2%3Alegacy%3A
```

`signature=v2…` survives because `=v2` isn't valid hex — a useful fingerprint of the bug.

## Why it matters

Signed URLs (PR promo links, password resets, magic links) fail validation, because the signature covers the exact original query string. The corruption is undetectable to a caller: `campaign_id$7164` reads as an ordinary opaque string, with no error or warning. Bytes below `0x80` are invertible from the residue character, but anything `>= 0x80` becomes `U+FFFD` and is gone.

## No workaround

- `messageFormat: "RAW"` and `"MESSAGE_FORMAT_RAW"` are rejected; only `MINIMAL`, `FULL_CONTENT`, `METADATA_ONLY`, `MESSAGE_FORMAT_UNSPECIFIED` are accepted.
- `get_message` and `get_thread` return identical bytes — no alternate path.
- No `attachments` / `attachmentIds` field on these messages, so the MIME payload isn't reachable that way.
Exposing a raw format (equivalent to the Gmail API's `format=raw`) would at least let callers decode correctly themselves.

## Related

`anthropics/claude-code#66010` is the same concern on the write path (`create_draft` rewriting URLs), filed against the wrong repo.

### What did you expect to happen?

Decode quoted-printable once, per the part's `Content-Transfer-Encoding`, then decode the bytes using the charset from `Content-Type`. All URL parameters with `=` followed by two characters should be correctly transmitted.

### Steps to reproduce

1. Connect to a Gmail MCP server
2. Using the Gmail connector, retrieve an email with an HTML body that normally includes the standard `X-UA-Compatible` meta tag `content=IE-edge` (verifiable through examining the actual source of the html email manually in Gmail).
3. Verify that `=ed` is transformed into `` (which appears as a character when decoded into UTF-8).

Note that this is an issue both in this verifiable (and common) string, as well as in critical situations such as password-reset emails or signed links.

### Area

Tool Discovery / Invocation

### MCP Server (if applicable)

Gmail

### Error messages or logs

```shell

```

### Additional context

This came up as an issue when building an artifact to aggregate recent PR emails with signed links as a Claude artifact.

_(Portions of this issue report and the investigation was written by Claude Opus 5.)_