docs: record the intermittent test_mainwindow failure as item 61

Two tests fail about one full run in twenty, and neither is caused by the card
list: a worktree at f72dba9, before any of that work, failed 3 of 12 runs, and
neither test was touched by it.

Recorded with what was measured and what was not. The cause is NOT established:
synthetic CPU load did not reproduce it, so the trigger is narrower than "the
machine is busy", and the entry says so rather than shipping a plausible guess
for the next reader to trust.

1 files changed, 43 insertions, 0 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 ae33e19..50d6c42 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
@@ -117,6 +117,7 @@ taking that too literally.
 | 58 | `message_zoom` documents a 0.5 to 3.0 range and enforces none of it | correctness | XS | **done** |
 | 59 | Archive and Mark all read shipped with the same icon | presentation | XS | **done** |
 | 60 | Next thread dead-ends on the last reply of an expanded thread | defect | XS | **done**; already fixed by 5487d58, see below |
+| 61 | `test_mainwindow` fails intermittently, about 1 run in 20 | testing | S | open; predates the card list, reproduced on f72dba9 |
 
 Sizes are rough: XS under an hour, S a sitting, M a session.
 
@@ -3708,6 +3709,48 @@ of an expanded thread**. A test that arrows down a collapsed list passes against
 the bug, since with nothing expanded every row is top-level and the arithmetic
 is accidentally correct.
 
+## 61. `test_mainwindow` fails intermittently, about 1 run in 20
+
+**Observed (2026-08-10), not user-reported.** A full `test_mainwindow` run
+occasionally fails with one or both of:
+
+- `anActionOnAMessageRowTagsThatMessageNotTheThread`: `pendingMessageIdsForTesting()`
+  is empty where one id is expected.
+- `aSuccessfulCronSyncDrainsTheEditedAccounts`: `work-channel` is still queued
+  after a successful sync.
+
+**It predates the card list, and that was measured rather than assumed.** A
+worktree at `f72dba9`, the commit before any of this work, failed 3 of 12 runs,
+which is a HIGHER rate than the branch's. Neither test was touched by the card
+list: `aSuccessfulCronSyncDrainsTheEditedAccounts` arrived in `d213bbf` on
+master, and `anActionOnAMessageRowTagsThatMessageNotTheThread` in `7c36486`,
+before the redesign began.
+
+**Not order dependence.** Both pass 15/15 when run alone by name, and a full
+suite passed 15/15 immediately after failing twice on the same binary. What
+distinguished the failing runs was other work happening on the machine at the
+time, which points at timing rather than at leaked state between tests.
+
+**Cause: not established.** Both tests are timer- and QProcess-driven, and the
+obvious hypothesis is that a `QTimer` or a `runExternalSync` step is being given
+a deadline that a loaded machine misses. That was not confirmed: synthetic CPU
+load across four cores did not reproduce it in 8 runs, so the trigger is
+narrower than "the machine is busy". Do not fix this from the hypothesis alone.
+
+**Approach.** Run the binary in a loop with `-v2` until it fails and keep the
+full log, rather than re-running until it passes. The two assertions are about
+state that should be set synchronously by the time they run, so the question to
+answer first is which step is actually asynchronous: if `sendThreadTagChange`
+reaches the worker on a queued connection, the test may be asserting before it
+lands, and the fix is a `QTRY_COMPARE` rather than a longer timeout.
+
+**Constraint.** A flaky test is worse than a missing one, because it teaches
+everyone to re-run the suite instead of reading it. This one already cost a
+false "green suite" report: it fired during the card-list merge check and was
+initially mistaken for a regression that change had introduced.
+
+**Size: S**, most of it in reproducing reliably rather than in the fix.
+
 ## Deferred, unsized, or split out
 
 Items noted while triaging but not part of the original list. Same numbering