feat: make Sync follow the account being looked at

Item 101. The sync run was already account-aware for pending edits and
consulted the account dropdown for nothing, so looking at one account and
pressing Sync collected every one of them.

pendingSyncChannels() now reads the dropdown as well as m_editedAccounts.
The two are a UNION rather than one replacing the other, which is the whole
safety property: looking at one account while having edited another is
ordinary, and a run that dropped the edited account's channel would strand
that write with nothing on screen to say so. All accounts is the empty key
and narrows nothing, so a full fetch stays what an unselected window asks
for. The existing fallback is untouched: an account whose section names no
channel still widens the run rather than being silently skipped.

syncStartedText() is the visibility half. A run opened with "Syncing..."
whether it covered one account or all of them; it now names what it covers.
The exit paths overwrite the label with their own wording immediately, so
the parameter is defaulted rather than threaded through them.

Four tests. The narrowing one asserts the channel list is EMPTY before the
gesture, since empty is what a full fetch looks like and a test starting
from a narrowed state could not tell the fix from a window that had never
widened. Mutation-checked twice: ignoring the selection fails three of
them, and replacing the pending set instead of unioning with it fails the
union test alone, which is the version that looks correct and loses a
write.

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

1 files changed, 1 insertions, 44 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 681200e..47c46fb 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.
 | 98 | "Important" adds the tag but cannot remove it, unlike every other toggle | defect | XS | **done** 2026-08-17, unreleased. Calls `everySelectedRowHasTag()`, as the entry required. Its reply test needed THREE different states (list-first thread, the reply's own thread, the reply) before it could tell the two wrong answers apart; with the reply defaulted to its thread's state the item 105 mutation stayed green, measured |
 | 99 | The unread action is labelled "Toggle unread" whichever way it will go | presentation | S | **done 2026-08-25**, unreleased, with 112: the user's note is ONE design across both. The label names the direction it will go, and the entry is hidden on a selection with no single state. `refreshUnreadAction()` reads the new three-valued `selectionTagPresence()` |
 | 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 |
+| 101 | Sync is account-aware for edits but not for the account the user is looking at | workflow | S | **done 2026-09-08**, unreleased. The user chose both halves the entry offered and narrowed the first: no second action, the existing Sync reads the account dropdown. Selected account narrows the run, All accounts is a full fetch as before, and the edited accounts are a UNION with the selection so a narrowed run cannot strand a write. The status line names what a run covers. See the closed 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+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 | XS | **done 2026-08-25**, hand-tested. The worker never reopened its read-only notmuch handle, so no query saw mail indexed after startup. Confirmed on a sync run from the application that added 20 messages: they appeared without a restart |
@@ -484,49 +484,6 @@ literals `lupdate` can see; a string built by concatenation is not translatable.
 
 **Size: S.** Mostly the mixed-selection and toolbar decisions, not the code.
 
-## 101. Sync is account-aware for edits but not for the account the user is looking at
-
-**Observed (user, from the notes):** "sync button should be account-aware."
-
-**Cause (verified in the code).** `MainWindow::pendingSyncChannels()`
-(`src/mainwindow.cpp:3550`) resolves channels from `m_editedAccounts`, the set of
-accounts the user has made EDITS in, and from nothing else. The account dropdown
-is not consulted. With nothing pending it returns empty on purpose, and
-`mailsync.sh` turns that into `mbsync -a`, every channel.
-
-**Item 49 built exactly this and the reasoning still holds.** The comment states
-it: with nothing pending the run is a FETCH, and narrowing a fetch to wherever
-the last edit happened would "quietly stop collecting mail everywhere else".
-Fetching is global by nature; carrying edits is not.
-
-**So this needs a decision, not a fix.** The note does not say which of two
-things the user means, and they are different features:
-
-*Sync only the selected account, on demand.* A deliberate "sync this account"
-that ignores the pending set, presumably beside the existing Sync rather than
-replacing it. Useful when one account is slow and the user wants their mail from
-another one now. The risk is the one item 49 named: a button that looks like
-Sync and quietly does not collect the rest of the mail.
-
-*Show which accounts a sync will cover.* No behaviour change at all, just making
-the existing account-awareness visible, since today the user cannot tell whether
-a run is narrowed or full. The status bar already names each channel as mbsync
-reaches it (item 42), so most of this exists.
-
-**Constraints.**
-
-- The account dropdown is a VIEW filter. Making it also steer sync couples two
-  things the user may reasonably want apart: looking at one account while
-  fetching all of them is the normal case, not an edge case.
-- Whatever narrows a run must still carry every pending edit, or an edit is
-  stranded with nothing on screen to say so. `pendingSyncChannels()` already
-  falls back to a full sync when it cannot resolve a channel for an edited
-  account, and that safety must survive.
-- An account with no `[account.<key>]` section, or one whose section names no
-  channel, has no channel to sync. The fallback covers it today.
-
-**Size: S** for the on-demand button, XS for the visibility half. Ask which.
-
 ## 113. No way to see a message's HTML source
 
 **Observed (user, 2026-08-17):** reviewing item 100's removals, "view source