docs: close item 103 and tick the delete-to-trash plan

Every step of the plan is done. Item 103's section moves to the closed file on
the same commit, per this repo's own rule, with its outcome recorded: what was
built, the ten defects hand testing found that the suite did not, and the two
process gaps closed alongside them.

The fact worth carrying forward is the one that damaged real mail. Under
mbsync's Create Both, a wrongly named origin folder propagates to the mail
server, so any code composing a folder name reaches the server whether it means
to or not.

Item 118, emptying the trash, remains deferred at the user's request.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 1 insertions, 52 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 6a5e64d..1f71006 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
@@ -167,7 +167,7 @@ taking that too literally.
 | 100 | The message pane offers Back, Forward, Reload and Save page, none of which mean anything | defect | XS | **done** 2026-08-17, unreleased. `MessageView::removeBrowserActions()` filters the standard menu by `pageAction()` POINTER, never by text; `ViewSource` went with them, and stranded separators are swept |
 | 101 | Sync is account-aware for edits but not for the account the user is looking at | workflow | S | open; item 49 built the edit half deliberately. Needs a decision, see the entry |
 | 102 | The rules table shows no note, so the field explaining a rule is invisible until it is opened | workflow | XS | **done** 2026-08-17, unreleased. A Note column before `ColumnCount`, so the appended Matches column stays last. Found a second defect on the way: `restoreState` REFUSES a header state with a different column count, and the sized flags were being set regardless |
-| 103 | What Delete does to mail on the server is undocumented and unverified | clarification | S | open; a question first, possibly no code at all |
+| 103 | What Delete does to mail on the server is undocumented and unverified | clarification | S+M | done; Delete moves to the account trash, with Restore and a stranded-mail cleanup. Section in the closed file |
 | 104 | Mail visible in Thunderbird never reaches qtmaildir | defect | ? | open, reported 2026-08-16, cause NOT established. Most likely outside this repo; see the entry before writing code |
 | 109 | A root card's own message is invisible to a message-scoped write | defect | S | **done** 2026-08-16, unreleased. Found by hand-testing 108. `applyMessageTagChange` and `messageById` searched only the loaded replies, and a root's message is never among them, so the ORDINARY gesture repainted nothing and wiped the pane's chip row |
 | 110 | A card and the message pane show tags belonging to a message's siblings | defect | S | **done** 2026-08-16, unreleased. Found by hand-testing 109 against a real 4-message thread. `ThreadSummary::tags` is notmuch's UNION; a card standing for one message drew it. Also the reason a root card could not repaint at all |
@@ -485,57 +485,6 @@ reaches it (item 42), so most of this exists.
 
 **Size: S** for the on-demand button, XS for the visibility half. Ask which.
 
-## 103. What Delete does to mail on the server is undocumented and unverified
-
-**Observed (user, from the notes):** "verify how 'delete' works", with two
-sub-questions of their own: "trash bin (?)" and "delete from server (?)".
-
-**This is a question first.** The user is not reporting a defect; they are saying
-they do not know what the button does to their mail, which for a destructive
-action is its own problem regardless of the answer.
-
-**What the code does (verified).** `src/mainwindow.cpp:825` adds and removes the
-`deleted` tag, and nothing else. It is a toggle, it goes through the undo stack,
-and it writes a notmuch tag.
-
-**What that means downstream is what needs verifying, and it is NOT in this
-repo.** `maildir.synchronize_flags` is true, so notmuch maps certain tags to
-Maildir filename flags, and mbsync carries filename flags to the server. Whether
-`deleted` is one of those, whether the user's `~/.mbsyncrc` has `Expunge Both`
-(it does, on every channel), and what each provider does with a message flagged
-deleted, together decide whether this button is reversible. The undo stack makes
-the TAG reversible; it says nothing about what a sync did with it in between.
-
-**Measured 2026-08-17, and the answer is that Delete does not delete.** notmuch's
-tag-to-flag table has no row for `deleted` and no `T` flag, confirmed by a probe
-on a throwaway database: `+deleted` left the filename untouched while the
-control `+flagged` immediately produced `:2,F`. mbsync carries filename flags, so
-`Expunge Both` never sees anything to expunge, and `assets/mailsync.sh` contains
-no delete path. Both sub-questions answer no: no trash bin, no deletion from the
-server, and the mail stays in the Maildir and the index forever.
-
-**Specified in
-`specs/2026-08-17-delete-to-trash-design.md`. Read that before writing code.**
-Delete becomes a real move into the account's trash folder, with a `Trash`
-filter beside the other built-ins and a Restore action. Three constraints decide
-whether the spec is worth opening:
-
-- It needs a **mandatory per-account `trash` key**, so an existing config warns
-  until five keys are added. User-visible: minor bump and an `### Upgrading`
-  note.
-- The worker gains its **first non-tag mutation**, a rename plus a reindex,
-  deliberately shaped as `moveMessages(ids, destFolder)` so Send in v2 reuses it
-  for Drafts and Sent.
-- **848 messages carry the old tag** while sitting in an inbox, and would be
-  invisibly half-deleted after the change. A repeatable menu entry queries them
-  into the list for review; it is not a startup migration.
-
-The no-confirmation rule survives, with its justification amended: the mail
-lands in a browsable folder, but reversibility is now bounded by the provider
-where the trash is purged on a timer.
-
-**Size: S** for the investigation, which is done. The build is **M**.
-
 ## 104. Mail visible in Thunderbird never reaches qtmaildir
 
 **Observed (user, from the notes):** "sync doesn't work compared to thunderbird.