feat(ui): disable Sync during a background sync, and blank the pane on Esc

Items 29 and 32.

29 was a constraint item 27 specified and that shipped unbuilt: while a
cron sync held the lock the Sync button stayed clickable, and pressing it
could only produce the EX_TEMPFAIL skip. The progress bar and the button
are now written by one updateSyncControls() taking both sync sources,
which the item asked for by name: two independent assignments, one per
path, means whichever finishes second wins, so a background sync ending
would re-enable the button in the middle of a local run.

Unknown re-enables the button, deliberately. It means /proc/locks could
not be read and nothing was observed, so leaving the button disabled
would strand it permanently wherever the lock cannot be seen.

32 adds a clear_pane action on Esc. It clears m_currentThreadId with the
pane, not merely alongside it, or a threadLoaded still in flight would
paint the thread straight back; and it cancels any pending mark-read,
since a thread blanked from view must not be marked read two seconds
later. The selection, the query and the undo stack are untouched.

The one real risk in 32 was Escape being stolen from the query
completer, the way Return was once lost to a window shortcut. Probed
rather than reasoned about: a popup consumes the key before a
window-level shortcut sees it, so the completer still dismisses.

Every test here was verified by reverting the code it covers.

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

1 files changed, 34 insertions, 2 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 4dab8a9..f7cf0e3 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
@@ -73,10 +73,10 @@ taking that too literally.
 | 26 | No way to add or remove an arbitrary tag from the UI | workflow | S | **done** |
 | 27 | The UI cannot see a sync it did not start | feedback | S | **done** |
 | 28 | Re-adding `unread` counts 2 unsynced changes, not 0 | correctness | S | open |
-| 29 | Sync button stays enabled during a background sync | feedback | XS | open |
+| 29 | Sync button stays enabled during a background sync | feedback | XS | **done** |
 | 30 | The blank right pane is wasted space | presentation | M | open |
 | 31 | The quit prompt has no highlighted default button | discoverability | XS | open, needs repro |
-| 32 | Esc does not blank the right pane | workflow | XS | open |
+| 32 | Esc does not blank the right pane | workflow | XS | **done** |
 | 33 | Status bar messages never expire | feedback | S | open |
 | 34 | No overview of the Maildir itself | information | M | open |
 | 35 | No refresh of the thread list after a sync | workflow | M | open |
@@ -1403,6 +1403,22 @@ share the progress bar; the button is the piece that was missed.
 - Exit 75 handling stays. Disabling the button makes the skip rarer, not
   impossible: cron can take the lock between the poll and the click.
 
+### Outcome (done)
+
+`updateSyncControls()` is the single function the constraint called for, taking
+`m_localSyncBusy` and `m_externalSyncBusy` and writing both the progress bar and
+the button. Neither sync path touches those widgets directly any more.
+
+**The external state is tracked as its own flag rather than read back from
+`SyncMonitor`.** An earlier version called `m_syncMonitor->state()` inside the
+update, which meant the handler received a state and then ignored it in favour
+of re-reading the source. Acting on what you were told is both easier to follow
+and testable without a live monitor.
+
+Unknown clears the busy flag exactly as Idle does, per the constraint. Verified
+by reverting that half: leaving it set on anything but Idle strands the button
+disabled, and the test catches it.
+
 ## 30. The blank right pane is wasted space
 
 **Observed (user, 2026-08-04):** with no thread selected the message pane is
@@ -1499,6 +1515,22 @@ race documented in `CLAUDE.md` and fixed in 0.8.0.
 - Decide what Escape does when the pane is already blank. Doing nothing is fine;
   clearing the selection as a second step would be surprising.
 
+### Outcome (done)
+
+A `clear_pane` action bound to `Esc`, registered like every other action so it
+reaches the menus, the shortcut reference and `[keys]`. It clears
+`m_currentThreadId` alongside the pane, and cancels any pending mark-read: a
+thread blanked from view must not be marked read two seconds later.
+
+**The completer keeps its Escape, verified by probe rather than by reading the
+code.** A popup consumes the key before a window-level shortcut sees it: with
+the popup open the popup's filter fires and the action does not, and with it
+closed the action fires. This was the one real risk in the item, since `Return`
+had already been lost to a window shortcut this way (item 21).
+
+Blanking is a view change only: the selection, the query and the undo stack are
+untouched, which a test pins.
+
 ## 33. Status bar messages never expire
 
 **Observed (user, 2026-08-04):** "the status bar should return to default status