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, 72 insertions, 0 deletions

diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
index 0972168..33bba8b 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
@@ -9670,3 +9670,75 @@ The test drives `onSyncFinished()` with the skip code after recording a real
 pending edit, since `runAutoSync()` correctly declines when there is nothing to
 carry and a fixture without one would arm nothing for a legitimate reason.
 Mutation-checked by removing the call.
+
+## 185. The message-pane bar offers Reply and Forward on a trashed message
+
+**Observed.** In the Trash view the bar above the message pane reads Reply and
+Forward. Neither is a thing to do with a message the user threw away, and the
+two actions that are, Restore and Delete permanently, are reachable only from
+the Message menu and the context menu.
+
+**Cause.** `MainWindow::refreshMessageBarActions()` (`mainwindow.cpp:2311`)
+picks the bar's message half from exactly one question, whether the displayed
+message is a draft:
+
+- a draft gets `edit_draft`
+- everything else gets `reply` and `forward`
+
+The trash is not a third case, so a trashed message takes the `else` branch.
+The knowledge needed is already computed elsewhere:
+`refreshTrashActions()` (`mainwindow.cpp:3735`) already decides `inTrash` and
+already toggles `delete` and `restore` on it, for the menus.
+
+**Approach.** Give the bar a third branch that asks the same `inTrash`
+question, and fill it with `restore` and `empty_trash`, or with `restore` and a
+per-selection permanent delete if the user wants one that is not the whole
+trash. The notes ask for both to grey out when nothing is selected, which is
+what the existing visibility rules already do for the menu entries; the bar
+should read the same actions rather than duplicating the predicate.
+
+**Constraints.**
+
+- **One source for the predicate.** `inTrash` is computed in
+  `refreshTrashActions()`; the bar must read that rather than deriving the
+  trash-ness a second way, or the two surfaces will disagree the first time a
+  view changes.
+- **"Delete permanently" for a selection does not exist yet.** Item 118 built
+  `empty_trash` for the whole trash and deliberately gave it the project's one
+  confirmation. A per-selection permanent delete is a SECOND irreversible
+  action and inherits that rule, including the confirmation and the absence of
+  a default shortcut. Decide with the user whether the bar offers the existing
+  whole-trash action or a new selection-scoped one; they are different items of
+  work.
+- **Item 186 rides with this**, since moving Delete into a bar that still
+  offers Reply on trashed mail improves nothing.
+
+**Closed 2026-08-29**, unreleased, the two built together. See the status table in the open file for what shipped.
+
+## 186. Delete sits on the main toolbar rather than beside Reply and Forward
+
+**Observed.** The user reads Delete as a message action and expects it in the
+message pane's own bar, with Reply and Forward, not on the window's main
+toolbar.
+
+**Cause.** Placement, nothing more: `toolBar->addAction(m_actions.value("delete"))`
+at `mainwindow.cpp:2251`, beside `archive`, `mark_all_read` and `undo`.
+
+**Approach.** Remove it from the main toolbar's list and add it to the
+`messageActions` list in `refreshMessageBarActions()`. The action itself, its
+scoping and its trash-aware visibility all stay exactly as they are.
+
+**Constraints.**
+
+- **Do it with item 185, not before it.** The bar is not trash-aware yet, so
+  Delete would land next to a Reply button offered on a trashed message.
+- **The bar hides over an empty pane** (`messageview.cpp:710`), so Delete
+  disappears when no message is displayed, where the toolbar kept it visible
+  and disabled. That is a behaviour change worth confirming rather than
+  discovering.
+- **The no-duplicate-icons test covers the toolbar**, so check
+  `test_mainwindow`'s icon and menu-reachability assertions still hold after
+  the move; the action stays in the Message menu either way.
+
+**Closed 2026-08-29**, unreleased, the two built together. See the status table in the open file for what shipped.
+