Summary

Adds a send_email_draft operation to the Slack button registry so a drafted email posted to Slack gets a one-click Send action alongside the existing "Review Draft" link button, gated by a native Slack confirmation dialog , sending is the first irreversible op in this registry.

See docs/design/slack-send-email-action.md for the full design writeup. Key points:

• Fixed a real data-loss gap first: GoogleMailManager.parseDraft discarded Gmail's own message.threadId. Naively echoing it back isn't enough on its own , Gmail assigns every message a threadId, including a brand-new draft's only message (threadId === message.id there, since it's the thread's first message). A reply's threadId differs from its own message id. parseDraft now derives threadId only when it represents a genuine reply, matching the same distinction createDraft already relies on when writing.
• send_email_draft reuses the existing sendDraft/getDraft/updateDraftSent/completeTaskByDraftId path rather than calling Gmail directly , it inherits assertProviderSideEffectsAllowed/withSuppressedDelivery for free. It's idempotent (checks analytics_draft_actions first; falls back to treating a getDraft 404 as "already sent," since that check is best-effort and Gmail deletes a draft immediately after sending), and refuses to send a draft with no recipient (drafting deliberately leaves to blank rather than guess one).
• Slack's native confirm dialog renders client-side before any webhook fires , a decline never reaches the server, so there's nothing to log, and any dynamic confirm text has to be baked in at message-build time. Added to the button schema (and its two duplicates in notifyUserTool.ts/notifyTool.ts), plus a hardcoded default specifically for send_email_draft so sending is never one click away regardless of what the agent's JSON contains.
• Updated the Slack bot's prompt so a drafted email gets both buttons when it has a recipient, and gave the agent the draft's own ID (listTasksTool.ts) , without it there was no value to put in the button's args.draftId.

What changed, by phase

1. ParsedDraft.threadId fix in the driver (lib/driver/google.ts, lib/driver/types.ts).
2. New send_email_draft op in operation-registry.ts.
3. confirm schema field + Block Kit rendering + hardcoded default (headless-response-schemas.ts, notifyUserTool.ts, notifyTool.ts, slack-block-kit.ts).
4. Prompt updates (slack-bot-chat.ts, operation-registry.ts's agent_prompt example, listTasksTool.ts).
5. A generic copy fix in slack-interactions.ts ("Click the button to retry" instead of a hardcoded "Click Accept," which was actively wrong for this op's "Send" label).
6. Tests: the op's happy path / idempotent short-circuit / empty-recipient rejection / no-connection failure / 404-fallback; the driver's reply-vs-fresh threadId derivation; Block Kit confirm rendering + default injection.

Explicitly not extended to iMessage tapbacks , a tapback is a single instant reaction with no confirm-dialog equivalent, so a "Send" tapback would be one fat-finger tap from an irreversible send with no gate at all.

Advisory findings (reviewed, judged non-blocking)

Libra flagged two things on the commit:

• No end-to-end Slack-interaction-payload test. True, but cancel_task/snooze_task/agent_prompt have none either , only buildApprovalApplyPrompt (a pure function) is tested; handleSlackInteraction has no test file today. New tests match existing precedent (testing the op's execute directly).
• invalid_grant handling on the new Gmail path. getDraft/sendDraft/create all route through the shared withGmailCall → handleOperationError wrapper (google.ts:5241-5249), which already checks invalid_grant generically for every Gmail call. This PR adds no new raw Gmail API surface , it calls the same existing send.ts functions every other send surface uses , so this handl