fix(messageview): drop the receive-only ribbon when the pane is blanked

MessageView::clear() resets the blocked-content bar, the stale notice and
the attachment bar by hand, and forgot the receive-only ribbon. Only
setReceiveOnlyAccount() ever hid it, and that is reached from
updateComposeActions(), which runs on a SELECTION change.

So the ribbon survived every route to a blank pane that is not one:
clear_pane, clear_selection, a new query, and a multi-row selection. It sat
over a blank pane, or over another account's mail, naming an account that
was no longer on screen and contradicting the live Reply button beside it.

Worth recording because it cost a test: the first one written for this
selected receive-only mail and then mail from a sending account, which is
how the report reads. It passed against the unfixed code, because that
gesture is precisely the one path that was already covered. The test now
drives clear_pane and a new query as well.

Its own trap, in the test rather than the code: clear_pane leaves the row
CURRENT, so re-selecting it emits no change and the ribbon is never
re-raised. The test moves away and back instead.

1 files changed, 1 insertions, 1 deletions

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 5b8d2ce..ba0293f 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
@@ -219,7 +219,7 @@ taking that too literally.
 | 147 | Toggle unread reads the same whichever way it will go | presentation | S | **duplicate of 99**, recorded 2026-08-23 from the notes. The notes ask for exactly what 99 describes: "Mark as read" on an unread message and the reverse. 99 already records that the label is harder than it looks, since a multi-row selection has no single direction |
 | 148 | Ctrl+W does not close the composer | discoverability | XS | open, 2026-08-23, from the notes. Verified: nothing binds `Ctrl+W` anywhere, and the composer has no close action of its own. Belongs with item 21's table rather than bound in isolation |
 | 149 | A reply's cursor lands on the attribution line, not on blank space | defect | XS | **done** 2026-08-24, unreleased. `quote_position` names where the QUOTE goes, so the cursor follows the reply and not the buffer: `End` under Above, `Start` under Below, where a shared `Start` had put it on the `On ... wrote:` line. The existing `theQuotePositionDecidesWhereTheQuoteLands` passed throughout, because the quote WAS in the right place |
-| 150 | The receive-only ribbon stays up after the message that raised it is gone | defect | S | open, 2026-08-24, from the notes. Observed in All accounts: a receive-only message raised the ribbon, and selecting a sendable account's mail left it visible. Verified: `MessageView::clear()` resets every other transient bar by hand (blocked-content label, stale notice, attachment bar) and does NOT touch `m_receiveOnlyRibbon`, which only `setReceiveOnlyAccount()` hides. So any path that repaints the pane without reaching `MainWindow::updateComposeActions()` strands it. Belongs in `clear()`, beside the other three, rather than as a new call site |
+| 150 | The receive-only ribbon stays up after the message that raised it is gone | defect | S | **done** 2026-08-24, unreleased. One line in `MessageView::clear()`, beside the blocked-content bar, the stale notice and the attachment bar it already reset by hand. Only `setReceiveOnlyAccount()` hid the ribbon, which every SELECTION change reaches, so a row-to-row move was never the reproducer: it survived the FOUR routes that blank the pane without one (`clear_pane`, `clear_selection`, a new query, a multi-row selection). The first test written for it passed against the defect for exactly that reason |
 | 151 | The message-pane bars blend into the UI and carry no severity | presentation | S | open, 2026-08-24, from the notes. The user's design: a yellow ground for warnings (the item 150 ribbon), a blue one for actions (remote content blocked), with the action's button right-aligned. Both are plain `QLabel`s today. Colour alone is not enough per CLAUDE.md's palette rule, and the pane is theme-aware, so the two grounds need light and dark values rather than one literal |
 | 152 | Signatures are not managed at all | v2 | ? | open, 2026-08-24, from the notes, asked for as a brainstorm rather than a build. Nothing in `[compose]` or `[account.*]` mentions a signature, so this is unspecified: per-account text, where it sits relative to the quote, and whether the HTML part gets its own form are all open. Needs the user to say what they picture before it can be sized |