feat(queries): drop pinning, the menu is every saved query's home

Item 94. The query row is the six built-in filters (Unread, Inbox,
Important, Sent, Drafts, Trash), which compose with the account
dropdown, and every saved query lives in the More queries menu. Nothing
has to decide which of the user's queries get button space, which is the
question item 93 would otherwise have had to answer.

SavedQuery::pinned is gone from the struct, the reader, the writer, the
save dialog's checkbox and the pin/unpin context action.

The stored key is stripped rather than left ignored, at the user's
choice. That has one non-obvious requirement: `pinned` stays named in
loadSavedQueries' `known` list precisely so it is NOT collected as an
unknown field, since those are preserved and written straight back. A
mutation removing that name puts the key in the file for ever.

Confirmed with the user before starting that the built-in set covers
their use, since removing pinning removes the escape hatch this item was
blocked on.

Tests: four pinning tests replaced by two on the new rule, four more
converted from buttons to menu entries. migrationPinsEveryEntry and
aStoredGeneratedQueryIsUnpinnedNotDropped are rewritten around the
property that outlived the flag rather than deleted: an entry must be
KEPT, which is what both assertions were really guarding.

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

1 files changed, 46 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 0f7181b..7314700 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
@@ -7392,3 +7392,49 @@ draft stayed disabled on a draft selected that way, and the reply family had
 the same blind spot without a test that could see it. It is now connected to
 both signals. Reading `currentRowChanged` is safe here for the reason
 `CLAUDE.md` gives: it answers "which row is current", and no count is read.
+
+## 94. `pinned` has nothing left to decide once the buttons are built-in
+
+**Observed (user, 2026-08-15),** thinking past item 93 rather than from the
+notes:
+
+> after we've migrated [...] we can drop my 4 redundant (by then) saved queries,
+> and there won't be a need for pinning anymore. The buttons will be driven by
+> the hardcoded queries, the menu will be the home for saved queries.
+
+**The end state this describes:** the query row is built-in filters ONLY, and
+every saved query lives in the menu. No mixing, so nothing has to decide which
+saved queries get button real estate, and `SavedQuery::pinned` is dead weight.
+
+**This also disposes of a problem item 93 would otherwise have to solve.** With
+both tiers sharing one row, something must order the four filters against the
+user's pinned queries. Under this end state the question does not arise.
+
+**Blocked on 93, and deliberately not part of it.** The user needs to live with
+the four buttons first and confirm they cover what they actually use. If one is
+wrong, pinning is the escape hatch, and it has to still be there to be used.
+Closing 93 and this together would remove the fallback before it was needed.
+
+**This is a user-visible removal, not a cleanup.** `pinned` shipped in 0.18.0:
+`SaveQueryDialog` offers "Show as a button" (`src/savequerydialog.cpp:104`) and
+the right-click menu offers "Move to menu" / "Show as a button"
+(`src/mainwindow.cpp:1797`). Anyone who put a saved query on the row loses that
+permanently. Semver on the user-visible surface makes it a minor bump with an
+`### Upgrading` note.
+
+**The stored field is a separate decision from the UI.** `pinned` is written to
+queries.json (`src/config.cpp:603`) and read back (`:542`). Two options, and the
+cheaper one is also the reversible one:
+
+- **Stop reading it, leave it in the file.** Harmless: an ignored key, preserved
+  by the unknown-field handling, and a build that reintroduces pinning would
+  find every user's setting intact.
+- **Strip it on the next save.** Cleaner file, and irreversible for anyone who
+  had it set.
+
+Prefer leaving it unless the user asks otherwise. No `kQueriesFormatVersion`
+bump either way: an ignored optional field is not a breaking change.
+
+**Size: S.** Removing a field, two UI affordances and their tests.
+
+**Closed 2026-08-24** (unreleased). See the status table row for the outcome.