Merge branch 'saved-queries': saved queries in a file of their own

Items 23 and 82. Saved queries move out of the [queries] INI section into
~/.config/qtmaildir/queries.json, gaining the three things the INI could not
express: an order, a pinned flag, and a per-query account scope. They can now be
created, edited, reordered, unpinned and deleted from the UI rather than only by
hand-editing a config file.

The INI could not carry order at all: QSettings reads a section through
childKeys(), which sorts alphabetically and never follows the file, so the
buttons could not be arranged. Migration reads the old section once, marks every
entry pinned so nothing moves on the first launch, and leaves the config file
byte-identical, since rewriting it with QSettings would drop the user's comments
and key order.

Sent stops being a hardcoded button and becomes an ordinary entry carrying
"generated": "sent". Its query is still composed from the accounts every time
it runs, so correcting a folder name still needs no edit here, but the row now
follows one rule instead of having one member the user could not move, rename or
remove.

Item 82 was found by hand-testing item 23 and fixed on the same branch: saving
worked and nothing else did, so a saved query could be created and never
changed. It also uncovered a defect that predated it, where rebuilding the row
with deleteLater() left the stale row answering findChild(), which was already
reachable from the save path.

Hand-tested throughout: the migration against the real config, saving, unpinning,
deleting, reordering, the read-only query field on a generated entry, and an
unpin surviving a restart.

1 files changed, 11 insertions, 0 deletions

diff --git a/docs/superpowers/specs/2026-08-13-saved-queries-design.md b/docs/superpowers/specs/2026-08-13-saved-queries-design.md
index 6d0019f..ba6b23e 100644
--- a/docs/superpowers/specs/2026-08-13-saved-queries-design.md
+++ b/docs/superpowers/specs/2026-08-13-saved-queries-design.md
@@ -160,6 +160,17 @@ Sent stays where it is. It is not a saved query, it is built from
 would mean generating a per-account path query into stored config, which is the
 duplication the `account`-key decision just rejected.
 
+## Editing and deleting are NOT here, and that is a defect
+
+This document specifies creating a saved query and says nothing about changing
+or removing one. That gap shipped: the first hand test produced "how do I unpin
+a query?", and the honest answer was a text editor. Recorded as **item 82**,
+sized S, and it should land before this work is called finished.
+
+Anything built there must merge the stored entry's `unknown` fields the way
+`saveCurrentQuery()` does, and must match a rename on the name the dialog was
+opened with rather than the one it returns.
+
 ## What is deliberately not here
 
 **Item 81, saving a query as a tagging rule.** A saved query is a view and costs