Merge branch 'compose-and-send': composing and sending mail

Item 123, built over 2026-08-20 to 2026-08-23 in thirteen tasks against
docs/superpowers/specs/2026-08-20-compose-and-send-design.md.

The application writes mail now. A composer window per message, markdown as
the body, drafts autosaving into the account's Maildir, and sending through a
per-account command on stdin rather than any network protocol of this
program's own. A countdown with an Undo stands between pressing Send and the
command running.

Two things came in alongside it. The notmuch auto-tagging hooks moved here
from the retiring `mailctl` project and learned that mail this application
files itself never arrived, so sent mail and drafts stop appearing in the
inbox. And the v1/v2 language is retired: semver on the user-visible surface
is the rule, and those labels described a split that composing made obsolete.

Hand tested against a fake send command rather than a real one, deliberately:
New, Reply and Forward all produce correct messages, a forwarded attachment
survives intact, and the sent copy is filed. That testing found the two
defects fixed on this branch, and both were invisible to the suite: a composer
orphaned by quitting the main window, and every sent message tagged `inbox`.

Twenty-two defects were found in the plan document's own draft code while
building it, which is why CLAUDE.md says to treat every code block in a plan
as a draft.

1 files changed, 41 insertions, 0 deletions

diff --git a/src/types.h b/src/types.h
index f4d387a..99c271d 100644
--- a/src/types.h
+++ b/src/types.h
@@ -239,6 +239,47 @@ struct DatabaseStats
     int tags = -1;      ///< Distinct tag names in the database.
 };
 
+/// What opens a composer. Built by MainWindow, consumed by ComposeWindow.
+///
+/// Built from the DATABASE, never from the model. The model's data comes from
+/// the query, so a row whose state has not been re-queried carries stale
+/// values, and a reply built from a stale row would carry the wrong
+/// recipients. This is the same rule Restore already follows.
+struct ComposeContext
+{
+    enum class Kind { New, Reply, ReplyAll, Forward };
+
+    QString accountKey;          ///< Which account sends. Plain data here; the resolution rules live with whatever builds this context.
+    Kind kind = Kind::New;
+    QString originalPath;        ///< The .eml being replied to or forwarded. Empty for New.
+    QString inReplyTo;           ///< Message-ID of the original.
+    QStringList references;      ///< The original's References plus its Message-ID.
+    QStringList to;              ///< Pre-filled, the user's own addresses already stripped.
+    QStringList cc;
+    QString subject;             ///< Re:/Fwd: prefixed, an existing prefix not doubled.
+    QString quotedBody;          ///< The >-prefixed original. Empty when the action does not quote.
+    bool seedHtml = false;       ///< Did the original carry a text/html part.
+    QStringList attachments;     ///< Carried forward for Forward, empty otherwise.
+};
+
+/// What the composer produces, consumed by MessageBuilder.
+///
+/// In-Reply-To and References are NOT optional. Without them a reply appears
+/// as an orphan thread in the sender's own client.
+struct OutgoingMessage
+{
+    QString accountKey;
+    QStringList to;
+    QStringList cc;
+    QStringList bcc;
+    QString subject;
+    QString markdownBody;        ///< The source text, exactly as typed.
+    bool sendHtml = false;       ///< The composer's per-message toggle.
+    QStringList attachments;     ///< Local paths, read at build time.
+    QString inReplyTo;
+    QStringList references;
+};
+
 Q_DECLARE_METATYPE(ThreadSummary)
 Q_DECLARE_METATYPE(MessageRef)
 Q_DECLARE_METATYPE(MessageNode)