feat: add email integration (read, send, manage)

[avoidwork]

Summary

Add email integration tools for reading, sending, and managing emails across Gmail, Outlook/MS Graph, and IMAP — including inbox organization and draft management.

Motivation

Email is the central nervous system of office work. The agent currently has zero capability to interact with email systems. There are no tools for reading/sending emails (Gmail, Outlook/MS Graph, IMAP), drafting responses, managing inbox organization, or calendar scheduling via email. This is a critical gap for any agent designed to assist with professional workflows. Users cannot ask the agent to triage their inbox, draft replies, or organize email threads.

Proposed Solution

Create an email skill that provides:

• Read email: Fetch messages from inbox, sent, drafts, or custom folders with filtering (by sender, date, subject, keyword)
• Send email: Compose and send emails with text/HTML body, attachments, and CC/BCC
• Draft management: Save drafts, list drafts, update/delete drafts
• Inbox organization: Label/archive messages, mark as read/unread, search
• Multi-provider support: Gmail (via Gmail API), Outlook/MS Graph (via Microsoft Graph API), and generic IMAP as fallback
• Authentication: OAuth2 for Gmail/Graph, or IMAP credentials for generic providers

Alternatives Considered

• Shell-based email tools (mutt, sendmail): fragile, requires local MTA setup, no API-level features.
• Single-provider only (Gmail): limits usability for enterprise/Outlook users.
• Web-scraping email: unreliable, breaks with UI changes, security concerns.

OpenSpec Note

This project uses OpenSpec for feature development. If this request is approved, I will:

1. Run /opsx:propose to generate a full proposal with specs and tasks
2. Iterate on the design before any code is written
3. Follow the task-driven implementation workflow

Additional Context

This should integrate with the existing calendar management gap (#780) for scheduling workflows. The email tool should support both push (webhook) and pull (polling) modes for new message detection.

Audit Findings (for Issue #779)

• src/tools/index.js — Tools are registered here with TOOL_PERMISSIONS and TOOL_CLASSIFICATIONS. New email tools would need entries in both maps (likely requiring network:outbound permission).
• src/config/config.js / src/config/loader.js — Configuration system; email credentials (API keys, OAuth tokens, IMAP passwords) would need secure storage here or in a dedicated credentials module.
• src/config/schemas/providers.js — Provider configuration schemas; email provider configs (Gmail, Graph, IMAP) would follow a similar pattern.
• src/tools/web.js — Existing web tool (webSearch, webExtract) uses network:outbound; email tools would follow the same permission model.
• src/agent/deepAgents.js — Agent orchestration; email tools would be registered alongside existing tools and available to agents via the tool map.
• src/tools/memory.js — Memory system; email conversations could be stored in memory for context continuity.
• Dependency note — Gmail API requires googleapis npm package. MS Graph requires @microsoft/microsoft-graph-client. IMAP requires nodemailer or imap-simple. OAuth flows add significant complexity — consider starting with API key/IMAP and adding OAuth later.
• Integration point — This issue cross-references fix: remove dead tool references (skillsList, skillView) from CODING.md and CODE_REVIEW.md #780 (calendar management). Email and calendar tools should share authentication and scheduling abstractions.

[avoidwork]

Fixed in #800.

[avoidwork]

Fixed in #800.