[BUG] Gmail MCP: update_draft on a correctly-threaded draft returns a new orphaned threadId

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Calling mcp__claude_ai_Gmail__update_draft on a draft that is correctly threaded (created via create_draft with replyToMessageId, whose response threadId matched the target thread) causes the response to come back with a brand-new, different threadId — even though only the htmlBody field was changed (no to, subject, or other threading-relevant fields were touched).

Reproduction

1. Create a draft reply to an existing thread:

``
create_draft({ to, subject, replyToMessageId: <id of last message in thread>, htmlBody })
`
Response threadId` matches the target thread — confirmed correct.

1. Call update_draft on that same draft, changing only inline style attributes in htmlBody (same recipients, same subject, same textual content):

``
update_draft({ draftId: <id from step 1>, htmlBody: <same content, only CSS style values changed> })
``

1. Observe the response: threadId no longer matches the original thread. In the reproduction, it came back equal to the response's own messageId — i.e. the draft had been detached into a new, standalone thread of its own.

What Should Happen?

update_draft should preserve the draft's existing threadId when the recipients and threading context are unchanged. A content-only edit (e.g. changing inline CSS on the htmlBody) should never change which thread a draft is attached to.

Impact

A draft correctly composed as a reply within an existing conversation thread silently becomes an orphaned standalone draft after any update_draft call — with no error and no warning. If sent without the user separately verifying (nothing in the tool response flags this), it lands in the recipient's inbox as an unthreaded new message, losing all prior conversation context — in a support/dispute case, this means the recipient loses the case number and history unless they happen to still have it in view. The only workaround found so far: never call update_draft on a threaded reply draft — discard it and rebuild via create_draft + replyToMessageId instead.

Likely related to the same missing In-Reply-To/References-header root cause discussed in #48017 and #45775, manifesting here via an explicit update_draft call rather than a draft-revision flow.

Error Messages/Logs

No error is returned — the call succeeds with a 200-equivalent response. The only signal that something went wrong is the changed threadId value in the response payload, which is easy to miss since most callers don't diff it against the prior value.