feat: put Star and Archive on the message bar too

Follows items 185 and 186, which established the pane's bar as where actions
on the displayed message live. Star and Archive are both selection-scoped and
fit that rule with nothing to decide; Archive leaves the main toolbar the way
Delete did, since the same icon in two places reads as two controls when the
toolbar is icon-only.

Ordered by what they do rather than by where they came from: answering the
message, then filing it, then destroying it, so the destructive button is not
between two that are not.

Mark all read deliberately stays on the main toolbar, at the user's decision.
It is the one action in this window that ignores the selection and acts on
every row in the view, so a bar whose every other entry acts on the one
displayed message is exactly where it must not be.

Item 140's toolbar test named archive as an example of a list-wide action.
That was never true of it, only untested, and this item reclassifies it: the
test now asserts archive LEFT the toolbar and keeps its guard on
mark_all_read, which is the action that genuinely is list-wide.

Closes item 189.

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

1 files changed, 65 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 33bba8b..26f90fa 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
@@ -9742,3 +9742,68 @@ scoping and its trash-aware visibility all stay exactly as they are.
 
 **Closed 2026-08-29**, unreleased, the two built together. See the status table in the open file for what shipped.
 
+## 189. The message bar carries only Reply, Forward and Delete
+
+**Observed.** The user asks for more of the standard message actions on the
+pane's own bar, now that items 185 and 186 established it as where actions on
+the displayed message live:
+
+- **Star (Important)**, per message or selection
+- **Archive**, per message or selection, possibly moved off the main toolbar
+  the way Delete was
+- **Mark all read**, raised as a question rather than a request
+
+**Cause.** Nothing is broken. The bar was filled with the reply pair when it
+was built (items 139 to 141) and has gained a branch at a time since: Edit
+draft for a draft (157), the trash trio and Delete (185, 186). Its rule has
+never been written down, which is why the third of these does not obviously
+fit.
+
+**The rule the bar has actually followed, stated.** An action belongs on the
+bar when it acts on **what the pane is displaying**. That is why Compose is on
+the main toolbar and Reply is not (item 140), and it is what made Delete's move
+correct in item 186.
+
+**So two of the three fit and one does not.**
+
+- **`flag`** is selection-scoped and is a toggle over the displayed message.
+  It fits with no decision needed.
+- **`archive`** is selection-scoped and fits the same way. The open part is
+  only whether it LEAVES the main toolbar, as Delete did, or appears on both.
+  Delete left because a duplicate reads as two different controls when the
+  toolbar is icon-only; the same argument applies here.
+- **`mark_all_read` does NOT fit.** It is the one action in the window that
+  deliberately ignores the selection (`markAllRead()`, "Every row, not the
+  selection"), and it is gated on the query being COMPLETE rather than on
+  anything being displayed. Putting a view-wide action on a bar whose every
+  other entry acts on one message is how a user marks a thousand threads read
+  meaning to mark one. This is the user's own `#discuss` and the answer from
+  here is: leave it on the main toolbar.
+
+**Approach.** Add `flag` and `archive` to the ordinary branch of
+`refreshMessageBarActions()` beside Reply, Forward and Delete. Decide with the
+user whether `archive` also comes off the main toolbar. Leave `mark_all_read`
+where it is unless the user overrules the reasoning above.
+
+**Constraints.**
+
+- **The trash branch must not grow with it**, though the reason is narrower
+  than it first looks. Delete already strips `inbox` alongside `unread` (the
+  `sendMove()` call in `trashMessages()`, since 2026-08-26), so on mail THIS
+  application deleted, Archive is genuinely a no-op, as the user observed.
+  The gap is mail trashed by ANOTHER client: nothing rewrote its tags, so it
+  can sit in a trash folder still carrying `inbox`. That is the same reason
+  the trash view is path-based rather than `tag:deleted`. On such a message
+  Archive is a real write that strips `inbox`, counts an unsynced change and
+  rewrites the Maildir filename under `synchronize_flags`, all with no visible
+  effect, which is item 168's shape exactly. Star is harmless there but adds a
+  fifth button to a bar that is already three. Whatever is added goes on the
+  ORDINARY branch only.
+- **Five buttons is the practical ceiling** on an icon-only bar next to the
+  view controls, so this is close to full. Anything after this needs the
+  overflow question answering rather than one more icon.
+- **Every action added must carry a distinct icon**, which the existing test
+  enforces for anything reachable from a toolbar. `flag` and `archive` already
+  have their own.
+
+**Closed 2026-08-29**, unreleased. Star and Archive added to the ordinary branch; Archive left the main toolbar; `mark_all_read` stays there by the user's decision, and the assertion that it does is now in the suite.