feat(email): Drafted column — agent-drafted replies awaiting approval

[itomek]

Goal

When the agent calls draft_reply (existing tool, see PR #965), the resulting draft lands in the dashboard's Drafted column with per-draft Send / Edit / Discard actions — not as text in a chat. This is the first column that demonstrates the dashboard's "agent does work, human approves" loop, which is the central trust-arc claim for this surface.

Why now

Fourth sub-issue under #1007. Comes after the state machine (#1010) because drafts are stateful items (drafted → approved → sent). Comes before persistence (#1007 sub-issue 7) because we want the loop visible even if it doesn't survive restart yet.

Scope

• When the agent invokes draft_reply, surface the result in the dashboard's Drafted column, not (only) in the chat stream.
• Each drafted-reply card displays:
  • Recipient(s), subject, body preview (truncated, expandable).
  • Three actions: Send (gates through existing TOOLS_REQUIRING_CONFIRMATION for send_draft), Edit (opens the draft for inline edit before send), Discard (state → dismissed, agent's draft is dropped).
• Send action reuses the existing send_draft tool — no parallel send path.
• Edit action: minimal inline editor (textarea), saved edits update the action store payload before send.
• Drafts persist in the in-session store across Refreshes during the same session.
• Render the count badge on the column header (e.g. "Drafted (2)").

Acceptance

• Agent's draft_reply results appear in the Drafted column with no chat-driving required.
• Send → confirmation dialog → send_draft tool fires → state moves to sent on success, item removed from Drafted column, summary appears in Archived-this-session column.
• Edit applies user changes to the draft before send; tested round-trip.
• Discard moves state to dismissed and the agent's draft is dropped (no future Refresh resurrects it in this session).
• Existing send_draft confirmation gating is preserved — no bypass path.
• Body preview truncation matches the existing 100-char convention from PR #965.
• Tests for the draft state transitions.

Out of scope

• Persistent drafts across restarts (sub-issue 7).
• Auto-drafting from background events (sub-issue 9).
• Multi-recipient cc/bcc UI beyond what send_draft already accepts.

Depends on

• #1010 (state machine + store)

Refs

• Parent: #1007
• Existing draft / send tooling: PR #965

[github-actions]

Thanks for the tight scope on this one — the build order under #1007 is clearly thought through, and #1010 → #1011 reads naturally (drafts are the first item type that moves between columns, so they're a great forcing function for the state machine).

A few code anchors that should make this cheap to wire, plus one thing worth deciding up front:

Existing pieces to reuse

• The draft_reply and send_draft tools already return structured envelopes via _envelope_ok (src/gaia/agents/email/tools/reply_tools.py:232,267). The Drafted column should be populating off the typed envelope payload (recipient, subject, body), not re-parsing the chat-stream rendering — that's the analog to how feat(email): Wire pre_scan_inbox to Triage Dashboard with explicit Refresh #1009 wires pre_scan_inbox.
• There's already a SQLite-backed email_drafts table in src/gaia/agents/email/action_store.py (it was added in feat(email): Gmail integration for Email Triage Agent #965 specifically so the send_draft confirmation dialog can show recipient + subject + body preview). The dashboard's Drafted card has the same data needs, so the backend payload is essentially free — what's new here is the per-card UI state.
• For the front-end store, src/gaia/apps/webui/src/stores/ already uses Zustand (agentChatStore.ts, chatStore.ts, etc.), which matches the convention feat(email): In-session task store + state machine for dashboard items #1010 calls for. The dashboard's draft items can live in the same store the state machine introduces, keyed by draft_id from the envelope.

One worth deciding before you implement

The email_drafts SQLite row is persistent (it's how undo works), but #1010 is explicit that the Zustand task store is in-session and wiped on restart. That's two different lifetimes for what looks like one item. Worth being explicit in the PR which is canonical for which columns: the SQLite row is the source of truth for the draft body (so a restart-then-send still works), but the Zustand store owns the column state (drafted | approved | sent | dismissed). That's the cleanest split and avoids resurrecting a dismissed draft from disk on the next page load — which the acceptance criterion bullet about "no future Refresh resurrects it in this session" implicitly requires.

Small consistency note

The 100-char truncation for body previews — worth grepping for the existing constant rather than re-defining it. PR #965 introduced the convention, and if it's already exported from reply_tools.py or the envelope helper, the dashboard card should pull from the same source so they don't drift.

Confirmation gating for send_draft is already wired through TOOLS_REQUIRING_CONFIRMATION at the agent level — the Send button just needs to invoke the tool the same way the chat surface does, no parallel approval path required. That's the cleanest way to satisfy the "no bypass" acceptance bullet.

Happy to review the PR when it's up.