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, 6 insertions, 20 deletions

diff --git a/src/config.cpp b/src/config.cpp
index cb6168f..23c7364 100644
--- a/src/config.cpp
+++ b/src/config.cpp
@@ -728,10 +728,6 @@ void Config::loadSavedQueries(const QString &configPath, QSettings &settings)
             SavedQuery query;
             query.name = name;
             query.query = settings.value(name).toString();
-            // Pinned, because these are buttons today. A migration that left
-            // them unpinned would empty the query row on the first launch
-            // after an upgrade, which reads as data loss.
-            query.pinned = true;
             m_savedQueries.append(query);
         }
         settings.endGroup();
@@ -804,7 +800,6 @@ void Config::loadSavedQueries(const QString &configPath, QSettings &settings)
         SavedQuery query;
         query.name = object.value(QStringLiteral("name")).toString();
         query.query = object.value(QStringLiteral("query")).toString();
-        query.pinned = object.value(QStringLiteral("pinned")).toBool(false);
         query.account = object.value(QStringLiteral("account")).toString();
         query.generated = object.value(QStringLiteral("generated")).toString();
         // A generator carries its own view mode, so "sent" is flat whether or
@@ -833,19 +828,12 @@ void Config::loadSavedQueries(const QString &configPath, QSettings &settings)
             continue;
         }
 
-        // A stored entry naming a generator now duplicates a BUILT-IN filter of
-        // the same name, since item 93 ships all four rather than storing them.
-        // 0.19.0 migrated the hardcoded Sent button into exactly such an entry,
-        // so every existing install has one.
-        //
-        // Unpinned, never dropped: the row would otherwise carry two Sent
-        // buttons, one the user's to edit and one not. Deleting it would be
-        // data loss on a file whose readers are supposed to preserve what they
-        // do not own, and an unpin is reversible from the UI.
-        if (query.isGenerated() && isKnownGenerator(query.generated))
-            query.pinned = false;
-
         for (auto it = object.begin(); it != object.end(); ++it) {
+            // `pinned` is listed although nothing reads it any more (item
+            // 94). Dropping it from this list would make it an UNKNOWN field,
+            // which is preserved and written back, and the user chose to strip
+            // it rather than carry it forward. This is the one place a retired
+            // key has to stay named to be forgotten.
             static const QStringList known = {
                 QStringLiteral("name"), QStringLiteral("query"),
                 QStringLiteral("pinned"), QStringLiteral("account"),
@@ -869,7 +857,7 @@ bool Config::saveSavedQueries() const
         // Only what carries information. The file is hand-editable, so a key
         // that always holds the same value, or one the generator already
         // implies, is just something the reader has to skip past. Same reason
-        // `pinned` and `account` are written only when set.
+        // `account` is written only when set.
         QJsonObject object;
         object.insert(QStringLiteral("name"), query.name);
         if (query.isGenerated()) {
@@ -877,8 +865,6 @@ bool Config::saveSavedQueries() const
         } else {
             object.insert(QStringLiteral("query"), query.query);
         }
-        if (query.pinned)
-            object.insert(QStringLiteral("pinned"), true);
         if (!query.account.isEmpty())
             object.insert(QStringLiteral("account"), query.account);
         // Skipped when the generator already implies it, which loadSavedQueries