feat: give the trash its own actions on the message bar

The pane's bar offered Reply and Forward on a message the user had thrown
away, which are the two things a trashed message is least likely to want,
while Restore and the purges lived only in menus.

The bar now has a third branch, asked before the draft one: a deleted draft
must come out of the trash before it can be edited. It is keyed on the
SELECTION being in a trash folder, the same predicate the menu entries use,
rather than on the trash VIEW, which disagree on mail reached from a search.
It carries Restore, Delete permanently and Empty trash, and only Restore is
tinted: the two purges are one act at two scopes and need no colour to tell
them from each other, only from the one action that gives mail back.

Delete moves here from the main toolbar in the same change (item 186). It
acts on the displayed message, like Reply and Forward, so it belongs on the
pane's bar by the rule items 139 to 141 settled for those two. It stays in
the Message menu and the context menu.

Delete permanently is new. It is Empty trash scoped to the selection, the
same purgeMessages() call with the ids resolved from the selection rather
than from a query, so it inherits both of that action's safeguards: it
confirms, naming the count, and it carries no default shortcut. One combined
thread:/id: query resolves a mixed selection, so a conversation and a reply
selected together still ask once.

The bar is refilled when the conversation digest arrives as well as on
selection, since a conversation's trash-ness is not known until every path
has been reported.

Closes items 185 and 186.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NY6poqw199LfFaXe5BHKNe

1 files changed, 16 insertions, 2 deletions

diff --git a/src/mainwindow.h b/src/mainwindow.h
index 9c93f4f..3829ae2 100644
--- a/src/mainwindow.h
+++ b/src/mainwindow.h
@@ -1272,9 +1272,23 @@ private:
     /// which holds whatever the current view happens to show.
     void emptyTrash();
 
+    /// Empty trash's sibling, scoped to the SELECTION rather than to the
+    /// account's whole trash. The act is identical, `purgeMessages()` in both
+    /// cases, and so are its safeguards: it confirms, and it carries no
+    /// default shortcut. Only where the ids come from differs, which is why
+    /// there are two entry points rather than a parameter.
+    ///
+    /// Asynchronous for the same reason emptyTrash() is: the count in the
+    /// dialog must be what will be destroyed, so a conversation row's
+    /// messages are resolved against the database rather than counted from
+    /// the model. The answer arrives at onThreadMessagesResolved() tagged
+    /// `purge_selection`.
+    void purgeSelected();
+
     /// The confirmation, and the only one in this application. Destroys
-    /// nothing if the user declines.
-    void confirmAndPurge(const QStringList &messageIds);
+    /// nothing if the user declines. \p where names the scope in the prompt,
+    /// since the two callers destroy very different amounts of mail.
+    void confirmAndPurge(const QStringList &messageIds, const QString &where);
 
     /// Moves each resolved message home, using the tags and paths the WORKER
     /// reported rather than anything the model holds.