fix(gmail): surface missing Message-ID on --reply-to-message-id (#512)

[solomonneas]

Fixes #512.

Problem

When gog gmail send --reply-to-message-id <id> (and the gmail drafts create
equivalent) resolves to a message whose metadata fetch returns no Message-ID
header, replyInfoFromMessage silently produces empty InReplyTo/References,
and buildRFC822 skips writing both threading headers because of its
TrimSpace == "" guards. The send proceeds with only threadId set, the CLI
reports success, the Gmail UI threads the reply, but recipients on non-Gmail
clients receive what looks like a brand-new message with no thread ancestry.

The reporter's repro inspects via gog gmail get <id> --format metadata --json,
but the default --format metadata allowlist only contained From, To, Cc,
Bcc, Subject, Date (plus List-Unsubscribe), so threading headers were
filtered out of the response regardless of whether they were actually set on
the wire. That made the bug genuinely silent end-to-end.

Fix

1. internal/cmd/gmail_send.go: fetchReplyInfo now returns a clear error
   when the explicit --reply-to-message-id path resolves to a message
   without a Message-ID header. Scoped to the explicit message-id path so
   drafts update's implicit thread-id continuity (which can legitimately
   include drafts in the lookback) is unaffected.
2. internal/cmd/gmail_get.go: default metadataHeaders for --format metadata now also include Message-ID, In-Reply-To, and References.
   Explicit --headers behavior is unchanged. JSON consumers reading
   .message.payload.headers will see up to three additional headers when
   present on the message.

Tests

• TestFetchReplyInfo_NoMessageIDFails — explicit reply target with no
  Message-ID returns an error mentioning Message-ID.
• TestFetchReplyInfo_ParentWithoutReferences — parent has only Message-ID,
  child References equals parent MID, In-Reply-To equals parent MID.
• TestFetchReplyInfo_ParentWithReferences — parent has both Message-ID and
  References, child References equals parent References + parent MID,
  In-Reply-To equals parent MID.
• TestExecute_GmailGet_Metadata_DefaultHeadersIncludeThreading — asserts the
  three new headers ride along in the default metadata request.

Verification

• make fmt clean, make lint reports 0 issues., make test green.
• go test -race -count=1 -run "Gmail|Reply" ./internal/cmd/ clean.
• Codex review pass (two rounds): no merge-blocking findings; one acknowledged
  follow-up (same silent-failure class on --thread-id) intentionally left
  out of scope for a surgical fix.

Note re #516

PR #516 also targets this issue but takes a different approach (using the
existing draft's own message ID as the reply target in drafts update).
Happy to defer if maintainers prefer that path; this PR addresses the
underlying silent-failure mode and the diagnostic gap.