feat(mail): reply-to-thread drafts

[rianjs]

Summary

Extend the `gro mail draft` command (added in #112 / #113) so it can compose a reply that Gmail (and any standards-compliant MUA) renders as a real reply: grouped under the original thread, with `In-Reply-To` and `References` headers pointing at the parent message.

The non-destructive philosophy carries over verbatim — the CLI still never calls `drafts.send`. The draft sits in the user's Drafts folder for explicit human review.

Reuse, don't rebuild

This is strictly additive on top of the #112 / #113 work. Specifically reuse:

• `internal/gmail/drafts.go` → `DraftMessage`, `DraftAttachment`, `DraftResult`, `buildMIME`, `CreateDraft`. Add fields to `DraftMessage`; do not introduce a parallel `ReplyMessage` type.
• The full MIME assembly pipeline (`MIME-Version: 1.0`, CRLF, base64 wrap, RFC 2047 subject encode, RFC 2231 filenames, multipart/mixed for attachments). Reply mode adds two more headers to the existing builder, nothing else.
• The header-injection guard in `guardHeaderInjection` — extend it to cover the new `InReplyTo` and `References` fields rather than writing a new guard.
• `internal/cmd/mail/draft.go` → `newDraftCommand`. Add two new flags to the existing command; do not create a separate `gro mail reply` command.
• The `MailClient` interface and `MockGmailClient` in `internal/cmd/mail/output.go` / `mock_test.go` — `CreateDraft` already handles arbitrary `DraftMessage` shapes, so no interface change is needed for the API call itself. Only add a new mock entry if we need it for the source-message lookup (which already exists as `GetMessage`, also already on the interface).
• The markdown rendering, plain/HTML mode flags, attachment handling, comma-separated address parsing, `--from` normalisation, and `cobra.NoArgs` — none of those need to change.
• The integration-tests.md draft section — append T21+ scenarios alongside the existing T1-T20.

If you find yourself duplicating any of these, stop and refactor to share instead.

Background

Today `gro mail draft` always creates a new standalone thread because:

• `DraftMessage` has no `ThreadID`, `InReplyTo`, or `References` fields.
• The Gmail API call doesn't set `Draft.Message.ThreadId`, so the server assigns a fresh thread.
• No `In-Reply-To`/`References` MIME headers are emitted, so even when forced into the right thread, downstream MUAs may not show the reply indicator.

Proposed usage

# Simplest form — let gro look up the source message
gro mail draft --reply-to <message-id> --body \"thanks, will review\"

# Overrides still work — recipients, subject, body source, attachments, --from
gro mail draft --reply-to <message-id> --cc colleague@example.com --body \"...\"
gro mail draft --reply-to <message-id> --subject \"Re: customised\" --body \"...\"

# Reply-all behaviour
gro mail draft --reply-to <message-id> --reply-all --body \"...\"

Without `--reply-to`, behaviour is unchanged from #113. With `--reply-to` and no overrides:

• To = original `From`
• Cc = (empty)
• Subject = `Re: ` if not already prefixed
• `In-Reply-To` = original `Message-Id`
• `References` = original `References` (if any) + original `Message-Id`
• `Draft.Message.ThreadId` = original thread ID

With `--reply-all`:

• To = original `From`
• Cc = original `To` + original `Cc`, minus the authenticated user

Explicit `--to`/`--cc`/`--bcc`/`--subject` override the derived values (use `cmd.Flags().Changed()`, matching the existing pattern in #113).

API surface (no scope change)

• `gmail.GmailModifyScope` already covers reading message headers and creating drafts. No `auth.AllScopes` change.
• Reuses existing `(*gmail.Client).GetMessage(ctx, id, includeBody=false)` to fetch headers — already on the `MailClient` interface.

Code changes (additive)

`internal/gmail/drafts.go`

Add three fields to the existing `DraftMessage`:
```go
type DraftMessage struct {
// ... existing fields from #113 ...
ThreadID string // empty = new thread; set = reply
InReplyTo string // original Message-Id (with angle brackets)
References []string // accumulated chain
}
```

Extend the existing `buildMIME` to emit `In-Reply-To` and `References` headers when set. Extend `guardHeaderInjection` to cover these two fields. Extend the existing `CreateDraft` body to set `Draft.Message.ThreadId = msg.ThreadID` before the API call.

`internal/cmd/mail/draft.go`

Add two flags to the existing `newDraftCommand`:

• `--reply-to ` (string)
• `--reply-all` (bool, only meaningful with `--reply-to`)

`RunE` gains a resolution step before existing validation:

1. If `--reply-to` is set, call `client.GetMessage(ctx, replyToID, false)` to read headers.
2. Derive defaults from the source message.
3. Explicit flags override derived values (cobra's `Changed()` — same pattern used for `--subject` and `--file` today).
4. Subject auto-prefix with `Re: ` if not already present (case-insensitive check).

Tests

• gmail layer: extend the existing tables in `drafts_test.go` — `In-Reply-To`/`References` emitted in MIME, parsed back via `net/mail`; injection guard rejects CR/LF in both; `ThreadId` propagates to the API request payload (extend the existing httptest wiring test).
• command layer: extend `draft_test.go` — `--reply-to` resolves source message → derived To/Subject/headers; `--reply-all` adds Cc; explicit `--to`/`--subject`/`--cc` override derived; `Re: Re: foo` doesn't double-prefix; missing source message fails before the create call.
• Integration tests: append T21+ scenarios to the existing draft section in `integration-tests.md` — reply lands inside the original thread in Gmail UI.

Out of scope

• No `forward` mode (different semantic — separate ticket).
• No quoting of the original message body (let the user write what they want; Gmail's web UI also doesn't auto-quote on reply unless you click the quote button).
• No `Reply-To:` header support (different from `--reply-to` flag despite the name overlap; defer until requested).

[rianjs]

Plan: #114 — reply-to-thread drafts

Extend gro mail draft to compose threaded replies. Strictly additive on top of #113 — same command, same MIME pipeline, same client interface. Adds two flags and propagates three new fields through the existing builder.

Scope (verbatim from ticket)

With --reply-to <messageID>:

• Look up source message via existing MailClient.GetMessage to read headers.
• Derive To = source From, Subject = Re: <orig> (case-insensitive, no double-prefix), In-Reply-To = source Message-Id, References = source References + source Message-Id, and Draft.Message.ThreadId = source ThreadID.
• --reply-all additionally sets Cc = source To + source Cc minus the authenticated user.
• Explicit --to/--cc/--bcc/--subject override derived values via cmd.Flags().Changed() (same pattern as existing --subject handling in feat(mail): add draft composition command #113).
• --reply-all without --reply-to is a validation error.

Out of scope (deferred per ticket): forward mode, body quoting, Reply-To: header support.

File-by-file edits

A. internal/gmail/messages.go — expose headers needed for reply derivation

The existing Message struct only carries From/To/Subject/Date. Add four fields and populate them in parseMessage:

type Message struct {
    // ... existing fields ...
    Cc         string `json:"cc,omitempty"`
    MessageID  string `json:"messageId,omitempty"`   // RFC 5322 "Message-Id" header
    References string `json:"references,omitempty"`  // raw "References" header value
    InReplyTo  string `json:"inReplyTo,omitempty"`   // raw "In-Reply-To" header value
}

Extend the switch in parseMessage to also capture cc, message-id, references, in-reply-to. Case-insensitive match already in place.

Why additive and not a separate accessor: these are RFC 5322 headers any Message carries; the existing struct is the authoritative shape. Adding new accessors would fork the surface.

Why not gate behind a flag: the cost is four extra struct fields and four header iterations per message — negligible. No other call site is affected (zero-value fields omitted via omitempty).

Verification: existing tests in messages_test.go still pass (make test). One new unit test asserts a synthesised *gmailv1.Message with all four headers parses correctly.

B. internal/gmail/drafts.go — three new DraftMessage fields, two new MIME headers, ThreadId on the API call

type DraftMessage struct {
    // ... existing fields ...
    ThreadID   string   // empty = new thread; set = reply
    InReplyTo  string   // original Message-Id (with angle brackets, as-is from source)
    References []string // accumulated chain; emitted space-separated per RFC 5322 §3.6.4
}

buildMIME changes (single insertion point, just before the Subject: line):

if msg.InReplyTo != "" {
    fmt.Fprintf(&buf, "In-Reply-To: %s\r\n", msg.InReplyTo)
}
if len(msg.References) > 0 {
    fmt.Fprintf(&buf, "References: %s\r\n", strings.Join(msg.References, " "))
}

guardHeaderInjection gains two checks (CR/LF on InReplyTo and each References entry). CreateDraft sets draft.Message.ThreadId = msg.ThreadID before .Do().

Why no header validation beyond CR/LF: Gmail tolerates malformed <...> brackets and will surface its own error. Pre-validating the angle-bracket format would duplicate Gmail's parser without protecting any real user behaviour.

Why References is []string not string: the field semantically is a list; the caller (command layer) needs to append. Joining at the emission boundary keeps the MIME formatter the sole owner of wire-format concerns.

Verification:

• New unit tests in drafts_test.go: TestBuildMIME_ReplyHeaders (asserts both headers present, correct values, parsed back via net/mail), TestBuildMIME_RejectsHeaderInjection_Reply (extends the existing table with InReplyTo CRLF and References LF), TestCreateDraft_APIWiring_PropagatesThreadId (extends the existing httptest test).
• Empty ThreadID/InReplyTo/References ⇒ no behaviour change (single new-thread test asserts headers absent).

C. internal/cmd/mail/draft.go — two new flags + reply-resolution step

Two flags:

cmd.Flags().StringVar(&replyTo, "reply-to", "", "Source Gmail message ID to reply to")
cmd.Flags().BoolVar(&replyAll, "reply-all", false, "Include the source To/Cc as Cc on the reply (requires --reply-to)")

RunE gains a new step before existing required-flag checks:

1. If --reply-all set but --reply-to not set → return validation error.
2. If --reply-to set:
   a. client.GetMessage(cmd.Context(), replyTo, false) — includeBody=false matches the ticket; we only need headers.
   b. derived := deriveReplyDefaults(src, replyAll, me string). For --reply-all we need the authenticated user's address to filter self out of the Cc list; obtain via client.GetProfile(cmd.Context()) (already on MailClient).
   c. Track which flags the user actually set with cmd.Flags().Changed() and apply derived values only where the user did not.

The derivation function lives in draft.go (no new file — single function, single caller):

func deriveReplyDefaults(src *gmail.Message, replyAll bool, me string) replyDerivation {
    out := replyDerivation{
        ThreadID:   src.ThreadID,
        InReplyTo:  src.MessageID,
        References: buildReferences(src),
        To:         []string{parseAddress(src.From)},
        Subject:    addRePrefix(src.Subject),
    }
    if replyAll {
        out.Cc = filterSelf(splitAddresses(src.To, src.Cc), me)
    }
    return out
}

• parseAddress strips display names via mail.ParseAddress (matches existing flag-parse behaviour from feat(mail): add draft composition command #113).
• splitAddresses calls mail.ParseAddressList on each non-empty header value and concatenates the bare addresses.
• filterSelf removes the authenticated user's address (case-insensitive equality on the local-part and domain) from the deduplicated slice.
• addRePrefix returns src.Subject unchanged if it starts with re: (case-insensitive, optional trailing space). Otherwise prepends "Re: ". No locale-specific variants (Sp/De/Fr Aw:, Sv:, etc.) — Gmail itself doesn't normalise those, so neither do we.
• buildReferences returns append(parsed(src.References), src.MessageID) where parsed splits on whitespace (RFC 5322 §3.6.4 token separator). Drops empty tokens.

Validation tweaks:

• --reply-to makes --to and --subject optional (existing code requires both). After derivation, validate that the resolved To is non-empty (defensive — Gmail always returns a From header but we shouldn't crash on a malformed source).
• Header-injection guard already covers --to/--cc/--bcc/--subject/--from. The new --reply-to flag value flows only into Gmail API calls, never into a header, so it doesn't need the CR/LF check (but I'll add one anyway for defence in depth — costs one line).

Why fetch the profile on every reply rather than caching: there's exactly one reply per CLI invocation; the call is ~50ms; caching would be a speculative optimisation.

Why no --in-reply-to/--references raw-override flags: the ticket explicitly lists them as out of scope. If a user needs that level of control, they can edit the draft in Gmail before sending.

Verification (command layer, draft_test.go):

• TestDraftCommand_ReplyTo_DerivesAllDefaults — synthetic source with From/To/Cc/Subject/Message-Id/References; assert resolved DraftMessage matches.
• TestDraftCommand_ReplyTo_ExplicitOverrides — --to, --cc, --subject each override derived value.
• TestDraftCommand_ReplyAll_AddsCc — Cc populated with source To+Cc minus self.
• TestDraftCommand_ReplyAll_RequiresReplyTo — --reply-all without --reply-to errors.
• TestDraftCommand_Reply_NoDoublePrefix — source subject "Re: foo" stays "Re: foo"; "re: foo" and "RE: foo" both stay as-is (case-insensitive); "Aw: foo" becomes "Re: Aw: foo" (we don't recognise locale variants).
• TestDraftCommand_ReplyTo_GetMessageFails — GetMessageFunc returns error; CreateDraft never called.
• TestDraftCommand_ReplyTo_PropagatesThreadID — seen.ThreadID == source.ThreadID.
• TestDraftCommand_ReplyTo_BuildsReferences — source has existing References; derived chain is <old> <src.Message-Id>.

D. internal/cmd/mail/mock_test.go — extend mock

MockGmailClient already has GetMessageFunc and GetProfileFunc from earlier work; nothing to add. Verify by grep.

E. README.md — Reply usage block under gro mail draft

Add a short subsection to the existing mail draft Commands entry showing the three usage forms from the ticket. No new command — just flag documentation. Mention in the Features bullet that draft can reply-to-thread.

F. integration-tests.md — append T21–T25

Five live-Gmail scenarios in the existing Draft Composition section:

• T21: --reply-to <id> only → draft lands inside source thread, In-Reply-To/References set, Re: prefix applied.
• T22: --reply-to <id> --reply-all → Cc populated, self filtered out.
• T23: --reply-to <id> --subject "Custom" → explicit subject wins.
• T24: --reply-to <id> --cc "extra@x.com" → explicit Cc replaces derived (consistent with override semantics; no "merge" surprise).
• T25: --reply-to <id> against a source whose subject is already "Re: foo" → no double prefix.

Setup block reuses ME="you@example.com" and adds SRC_ID=$(./bin/gro mail search "subject:test" --json | jq -r '.[0].id') to obtain a real source message ID.

Order of operations

1. Add the four new fields to gmail.Message and extend parseMessage. Run make test — gates 0.
2. Add the three new fields to DraftMessage; extend buildMIME, guardHeaderInjection, CreateDraft. Add new gmail-layer tests. make test — gates 1.
3. Add the two new flags + resolution logic + helpers in draft.go. Add command-layer tests. make test — gates 2.
4. README + integration-tests.md additions. make check — gates 3.
5. Commit, push, PR.

What I deliberately decline to do

• No new gro mail reply command. Ticket forbids it.
• No new ReplyMessage type. Ticket forbids it.
• No Reply-To: MIME header. Out of scope.
• No body quoting. Out of scope.
• No fancy thread-ID validation. Gmail's API surfaces its own errors clearly.
• No new MailClient methods. GetMessage and GetProfile are already on the interface.
• No refactor of existing feat(mail): add draft composition command #113 code paths. Every change is an insertion, not a rewrite.