feat(ui): give the message pane its own action bar

Items 139, 140 and 141, built together because the seam between them is
wasted work: 140 needs a container and 141 is that container.

The main toolbar had grown to mix two scopes. Sync, Archive, Delete, Mark
all read and Undo act on the list or the selection; Compose, Reply and
Forward are about one message. With everything in one row the distinction
was invisible, and Forward was on no toolbar at all, reachable only from the
Message menu, which is item 139.

Compose, Reply and Forward now sit on a bar above the message pane, and
LEAVE the main toolbar rather than gaining a second home: that is what makes
the toolbar's remaining contents mean one thing. Toggle HTML joins them at
the right end, separated by an expanding spacer, since changing how a
message is displayed is a different scope from acting on it. That layout was
the open design question item 141 recorded, and it was settled with the user
rather than guessed.

The actions are MainWindow's own QAction objects shown a second time, never
copies: a duplicate would carry its own enablement and drift from the menu
entry updateComposeActions() keeps in step. MessageView::setBarActions() is
the seam, so the pane still knows nothing about the window's action map.

Two things worth recording:

QToolBar has no addStretch(), so the separation is an expanding spacer
widget. A test asserting only on action ORDER passes with that spacer
deleted, measured, so it asserts on the spacer's size policy instead.

noTwoActionsShareAnIcon looked up the toolbar with an unnamed
findChild<QToolBar*>(). There are two toolbars now, so it is pinned to
main_toolbar: pointed at the pane's bar it would have asserted that a
thread action is absent from a bar that never holds any, and passed while
the rule it exists for went unchecked.

2 files changed, 69 insertions, 69 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 a4aae42..d1daa57 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
@@ -7123,3 +7123,69 @@ real context-menu event and the offscreen platform cannot deliver one. The
 honest options the entry named were an assertion on the production menu or a
 hand test; the first is impossible here, so it is the second, recorded in the
 test so nobody adds an assertion that appears to cover it.
+
+## 139. Forward is reachable only from the Message menu
+
+**Observed.** There is no Forward button anywhere in the interface. The action
+exists and works; it is in the Message menu and nowhere else.
+
+**Cause, verified 2026-08-23.** `mainwindow.cpp:1714` registers the action and
+`1763` adds it to `messageMenu`. The toolbar block at `1975-1994` adds Compose
+and Reply but never Forward, so two thirds of the message-action set are
+visible and the third is not.
+
+**Approach.** One line, if the toolbar is where it belongs. It probably is not:
+item 140 records the user's own view that all three belong over the message
+pane instead, which makes this item the cheap half of that one. Build 140 and
+this closes with it; build this alone only if 140 is deferred.
+
+**Constraints.** The no-duplicate-icons rule covers any action that can reach
+the toolbar, so Forward needs an icon distinct from Reply's rather than a
+variant of it.
+
+---
+
+## 140. Compose, Reply and Forward belong over the message pane
+
+**Observed.** The user's note: "'Write new message' and 'reply' live next to
+the other icon only buttons, but they belong in a new bar on top of the message
+pane, together with 'Forward'."
+
+**Cause.** Not a defect. The toolbar grew by accretion and now mixes two
+different scopes: Sync, Archive, Delete, Mark all read and Undo act on the LIST
+or on the selection, while Compose, Reply and Forward are about a message. The
+main toolbar reads as the place for everything, so the distinction is invisible.
+
+**Approach.** A bar above the message pane carrying the three message actions,
+and the main toolbar keeping the list-wide ones. Compose is arguably neither,
+since it needs no message at all; the user grouped it with the other two, and
+that grouping is theirs to make. It shares the container item 141 introduces.
+
+**Constraints.** The actions themselves do not move: they stay in
+`m_actions`, keep their shortcuts, and keep their menu entries, which is what
+`everyActionIsReachableFromAMenu()` asserts on. This is a second presentation
+of the same `QAction`s. Absorbs item 139.
+
+---
+
+## 141. The message pane has no button bar of its own
+
+**Observed.** The user asks for "a button bar in the message pane area", and
+names `toggle_html` as a control that would fit it.
+
+**Cause.** Nothing exists to hang such a control on. The pane is a header
+label, the web view, the attachment bar and the tag strip; a per-message
+control has no home, which is why `toggle_html` lives in a menu.
+
+**Approach.** The container item 140 needs. Whether it holds only the three
+message actions, only view controls like `toggle_html`, or both is the design
+question, and it should be settled with the user before building: a bar that
+mixes "act on this message" with "change how I am looking at it" is the same
+confusion item 140 exists to remove, one level down.
+
+**Constraints.** `MessageView` is built inline in its own class rather than
+from named widget classes, per CLAUDE.md, and this should not become the
+exception. Size assumes 140 and 141 are built together; separately they are
+each S and the seam between them is wasted work.
+
+---
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index 0b1195e..7f9c606 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -208,9 +208,9 @@ taking that too literally.
 | 136 | `undoMovesTheMessageBack` fails when run ALONE, passes in the full suite | defect | ? | open, 2026-08-21, re-measured 2026-08-24 and it is not what the row said. Filed as an intermittent race (1 in 6); it is in fact **deterministic on the selection**: 6 failures in 6 when named on the command line, and 0 failures in the full 258-test run, on a clean tree with the day's work stashed out. All three of its 15s `QTRY` timeouts expire, giving 45s against a 25s whole-suite run, so undo never moves the file rather than losing a race. A test that needs its predecessors is the likely shape (the `init()` lock-table fixture of item 61 is one candidate), which makes it a TEST defect until shown otherwise. Not caused by item 149 |
 | 137 | A reply to a message that arrived at two accounts can come from the wrong one | defect | S | open, 2026-08-22, found while building item 123 task 12. `ComposeContextBuilder::accountForReply()` takes `messagePaths` PLURAL to disambiguate, and nothing upstream ever gives it more than one path, so the disambiguation is inert |
 | 138 | No Drafts filter beside Sent and Trash | workflow | S | open, 2026-08-23, from the notes. Verified: `kQueryGenerators` has no `drafts` entry, though every account already configures a `drafts` folder. Follows the `sent` generator exactly, which composes per-account folders rather than matching a tag |
-| 139 | Forward is reachable only from the Message menu | discoverability | XS | open, 2026-08-23, from the notes. Verified: `forward` is added to `messageMenu` and to no toolbar. Compose and Reply are on the toolbar, so the third member of the set is the only one hidden |
-| 140 | Compose, Reply and Forward belong over the message pane, not on the main toolbar | presentation | M | open, 2026-08-23, from the notes. The user's design: a bar of its own above the message pane carrying the three message actions, leaving the main toolbar for list-wide operations. Absorbs 139, which is the same three buttons in a worse place. See also 141 |
-| 141 | The message pane has no button bar of its own | presentation | M | open, 2026-08-23, from the notes. The container 140 needs, and the home the user names for a `toggle_html` control. Sized as one item with 140 if built together |
+| 139 | Forward is reachable only from the Message menu | discoverability | XS | **done** 2026-08-24, unreleased, inside 140/141 as that entry said it would be. Forward is on the message pane's own bar with Compose and Reply |
+| 140 | Compose, Reply and Forward belong over the message pane, not on the main toolbar | presentation | M | **done** 2026-08-24, unreleased, with 139 and 141. The three actions LEAVE the main toolbar rather than gaining a second home, which is what makes the toolbar's remaining contents mean one thing (list-wide operations). Same `QAction` objects shown twice over, never copies, so enablement and the menu entries stay single-sourced |
+| 141 | The message pane has no button bar of its own | presentation | M | **done** 2026-08-24, unreleased, with 139 and 140. The design question the entry flagged was settled with the user: message actions left, view controls right, separated by an expanding spacer, with `toggle_html` the first of the latter. `MessageView::setBarActions()` is the seam, so the pane still knows nothing about `MainWindow`'s action map. Two traps: a toolbar has no `addStretch()`, and `noTwoActionsShareAnIcon` took an UNNAMED `findChild<QToolBar*>` which now has two candidates, so it is pinned to `main_toolbar` or it would assert against the wrong bar and pass while the rule went unchecked |
 | 142 | The composer's formatting buttons share a toolbar with Send and Attach | presentation | S | open, 2026-08-23, from the notes. Verified: one `addToolBar` carries Bold through Quote, then Attach, Remove attachment and Send. The user reads the row as a menu bar that is not one. Move the formatting half down to sit directly above the editor, beside the HTML checkbox |
 | 143 | The formatting buttons are text, where every editor uses icons | presentation | XS | open, 2026-08-23, from the notes. Follows 142, and cheap once the row moves. `QIcon::fromTheme` per CLAUDE.md's chrome rule, with the text kept as the tooltip |
 | 144 | "Also send a formatted copy" is prominent and does not say what it does | presentation | XS | open, 2026-08-23, from the notes. It means "send an HTML part as well as plain text", which the label never says. Secondary to writing the message, so it should read as such |
@@ -1375,72 +1375,6 @@ importing the other.
 
 ---
 
-## 139. Forward is reachable only from the Message menu
-
-**Observed.** There is no Forward button anywhere in the interface. The action
-exists and works; it is in the Message menu and nowhere else.
-
-**Cause, verified 2026-08-23.** `mainwindow.cpp:1714` registers the action and
-`1763` adds it to `messageMenu`. The toolbar block at `1975-1994` adds Compose
-and Reply but never Forward, so two thirds of the message-action set are
-visible and the third is not.
-
-**Approach.** One line, if the toolbar is where it belongs. It probably is not:
-item 140 records the user's own view that all three belong over the message
-pane instead, which makes this item the cheap half of that one. Build 140 and
-this closes with it; build this alone only if 140 is deferred.
-
-**Constraints.** The no-duplicate-icons rule covers any action that can reach
-the toolbar, so Forward needs an icon distinct from Reply's rather than a
-variant of it.
-
----
-
-## 140. Compose, Reply and Forward belong over the message pane
-
-**Observed.** The user's note: "'Write new message' and 'reply' live next to
-the other icon only buttons, but they belong in a new bar on top of the message
-pane, together with 'Forward'."
-
-**Cause.** Not a defect. The toolbar grew by accretion and now mixes two
-different scopes: Sync, Archive, Delete, Mark all read and Undo act on the LIST
-or on the selection, while Compose, Reply and Forward are about a message. The
-main toolbar reads as the place for everything, so the distinction is invisible.
-
-**Approach.** A bar above the message pane carrying the three message actions,
-and the main toolbar keeping the list-wide ones. Compose is arguably neither,
-since it needs no message at all; the user grouped it with the other two, and
-that grouping is theirs to make. It shares the container item 141 introduces.
-
-**Constraints.** The actions themselves do not move: they stay in
-`m_actions`, keep their shortcuts, and keep their menu entries, which is what
-`everyActionIsReachableFromAMenu()` asserts on. This is a second presentation
-of the same `QAction`s. Absorbs item 139.
-
----
-
-## 141. The message pane has no button bar of its own
-
-**Observed.** The user asks for "a button bar in the message pane area", and
-names `toggle_html` as a control that would fit it.
-
-**Cause.** Nothing exists to hang such a control on. The pane is a header
-label, the web view, the attachment bar and the tag strip; a per-message
-control has no home, which is why `toggle_html` lives in a menu.
-
-**Approach.** The container item 140 needs. Whether it holds only the three
-message actions, only view controls like `toggle_html`, or both is the design
-question, and it should be settled with the user before building: a bar that
-mixes "act on this message" with "change how I am looking at it" is the same
-confusion item 140 exists to remove, one level down.
-
-**Constraints.** `MessageView` is built inline in its own class rather than
-from named widget classes, per CLAUDE.md, and this should not become the
-exception. Size assumes 140 and 141 are built together; separately they are
-each S and the seam between them is wasted work.
-
----
-
 ## 142. The composer's formatting buttons share a toolbar with Send and Attach
 
 **Observed.** The user reads the composer's top row as a menu bar that is not