docs: spec built-in filters as item 93, fold item 90 into it

Explaining item 90 to the user produced a reframing rather than a fix. The
buttons and the "more queries" menu are two different kinds of thing sharing
one mechanism: a filter narrows whatever the user is looking at and should
compose with the account dropdown, while a saved query is a self-contained
destination entitled to set the account itself.

Nothing ships as a default today, so the buttons are whatever the user pinned,
which the queries.json migration did to every [queries] entry. That drift is
the defect.

Item 93 ships four built-in filters, Unread, Inbox, Flagged and Sent, as
generated entries in the closed kQueryGenerators set that already exists for
Sent. The user's own pinned queries are unpinned rather than deleted once the
buttons are confirmed working.

Three findings from reading the code, all in the spec. A generator must answer
per account rather than having its all-accounts query wrapped in a scope, or
Sent becomes path:"a/**" and (path:"a/Sent/**" or path:"b/Sent/**"), which
returns the right rows only because path: is hierarchical. Sent is flat and
the other three are not, so the four match in scope and not in view mode. And
m_accountBox has no signal connected to it, which is now a decision rather
than an omission: changing the account runs nothing, the button is the verb.

Item 90's section moves to the closed file, kept in full because its cause and
the rules preview that motivated the reset are still true of the code.

1 files changed, 62 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 730c722..ba8b99e 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
@@ -5039,3 +5039,65 @@ when the write is moved above the guard.
 
 The cold-cache cost measured above was not touched and should not be. Nothing
 about the timing changed.
+
+## 90. A saved-query button clears the account selection
+
+**Observed (user, notes):** "select an account and hit the 'unread' button, the
+panel should show unread messages from that account only, instead it refreshes
+the 'all accounts' list."
+
+**Cause, and it is a deliberate line, not an oversight.**
+`MainWindow::runSavedQuery()` (`src/mainwindow.cpp:1907`) resets the account box
+whenever the saved query names no account:
+
+```cpp
+const int index = saved.account.isEmpty()
+                      ? m_accountBox->findData(QString())
+                      : m_accountBox->findData(saved.account);
+if (index >= 0)
+    m_accountBox->setCurrentIndex(index);
+```
+
+The comment above it states the intent: "An unscoped query CLEARS the selection
+rather than inheriting whatever was there, which is the defect the rules preview
+hit." `runQuery()` (`:2020`) then scopes whatever the box holds, so with the
+reset removed the button would inherit the selection and the user would get what
+they asked for.
+
+**So this is a decision, not a bug to fix quietly.** Two behaviours are
+defensible and each breaks the other's case:
+
+- **Inherit.** The account box is a persistent scope and the buttons are
+  queries within it. This is what the note asks for. The risk is the one the
+  comment names: a query that already scopes itself, such as a rules preview
+  with `path:"work/**"`, gets scoped twice and matches nothing.
+- **Reset.** A saved query is self-contained and says exactly what it shows.
+  This is what ships. Its cost is that the account dropdown looks like a filter
+  and silently is not.
+
+**Approach.** Ask the user which they want before writing anything. If it is
+inherit, the narrow version is to inherit only for hand-written and generated
+entries and keep the reset for a preview, since a preview is the one caller that
+supplies its own path; the rules preview already forces index 0 itself at
+`:1637`, so it does not depend on this line.
+
+**Constraints.**
+
+- Whatever is chosen, one rule for every saved-query surface: the buttons, the
+  menu and the dropdown all reach `runSavedQuery()`, and three behaviours here
+  would be worse than either one.
+- A saved query that DOES name an account must keep overriding the box. That is
+  not in question and no test should lose it.
+- `Account::scopedQuery()` is the only place a scope is applied. Do not add a
+  second one to make a caller behave.
+
+**Folded into item 93 on 2026-08-15, not fixed in place.** Explaining this item
+to the user produced the reframing in 93: the button that misbehaves here should
+never have been a saved query, so `runSavedQuery()` keeps this behaviour and the
+filters get their own. The narrow fix considered here, inheriting the selection
+for unscoped entries, was rejected because it would also make every unscoped
+MENU entry compose, and those are the self-contained destinations that should
+keep resetting the account.
+
+Kept in full because the cause, the comment defending the reset, and the rules
+preview that motivated it are all still true of the code.