feat(email): voice/style-matched drafting from Sent history

[kovtcharov-amd]

P3 stretch goal for Milestone 40 (v0.21.0). Not required for the milestone; promote only if capacity allows.

Draft replies in the user's own voice by learning tone/style from their Sent history, rather than producing a blank-bodied scaffold. Fits GAIA's local-first model — the style profile is built from private Sent mail that should never leave the device.

Cross-link: extends the already-closed #1269 (draft reply with tone + context matching), which matches tone per request; this issue adds a persisted voice/style profile derived from Sent history. Related: #704 (Personal CRM, per-person tone matching).

Gap reference: capability gap G4 in the email use-case doc.

Acceptance criteria

• Build a local style profile from a sample of the user's Sent messages.
• draft_reply produces a body reflecting that profile (greeting/sign-off/length/formality), still returned for approval — nothing auto-sent (feat(email): send with confirmation (never auto-send) #1264).
• Profile is local-only; no Sent content leaves the device.

Test acceptance criteria

• Judge-scored: voice-matched drafts beat the blank-scaffold baseline on style-match against the feat(eval): generate + commit labelled email-triage corpus + gemma4 baseline #1230 corpus.
• Unit test: draft generation triggers NO send side-effect.

[github-actions]

This is a clean extension of the existing draft path and fits GAIA's local-first model well — the whole style profile can be derived and stored on-device.

A few notes for whoever picks this up:

• The email agent now ships as the standalone hub package hub/agents/python/email/gaia_agent_email/. draft_reply lives in tools/reply_tools.py and receives a body that the LLM has already composed in the agent loop — so the voice profile plugs into the draft-composition prompt, not into draft_reply itself.
• Two of the acceptance criteria are already partly satisfied: nothing auto-sends because send_draft/send_now/forward_message are gated by TOOLS_REQUIRING_CONFIRMATION, with regression coverage in tests/integration/test_never_auto_send.py and tests/unit/agents/test_email_agent_confirmation.py. The "no send side-effect" unit test can build on those.
• Persist the profile next to the existing SQLite action store (action_store.py) so it stays local-only — no Sent content leaves the device, matching feat(email): send with confirmation (never auto-send) #1264/feat(email): draft reply with tone + context matching #1269.
• For the judge-scored criterion, wire a style_match scenario into the eval harness against the feat(eval): generate + commit labelled email-triage corpus + gemma4 baseline #1230 corpus so voice-matched drafts can be diffed against the blank-scaffold baseline.

Since this is a P3 stretch goal, no urgency — but the pattern from #1269 (per-request tone) is the natural starting point to extend into a persisted profile.

[harryfrzz]

Hey @kovtcharov-amd! I'd love to work on this feature request as local-first, on-device style modelling is right in my lane. Could you assign it to me? I'm planning to implement it as a persisted, on-device style profile from a sample of the user's sent mail (greeting/sign-off, length, formality) and feed it into the existing draft_reply, additive and approval-gated, also nothing leaves the box and nothing auto-sent