feat: have the sync script report what it did

Item 174, and half of item 125.

The premise was corrected before any code. The note asks for an external
`notmuch new` to clear the pending count; it must not. That count means
tag mutations not yet known to have reached the MAIL STORE, which is the
server: an edit is in notmuch the moment it is made, and what is
outstanding is mbsync pushing the renamed Maildir files. `notmuch new`
re-indexes local files and pushes nothing, so clearing on it would tell
the user their work was safe to quit on while it was still local. The
entry's own proposal to watch notmuch_database_get_revision() was
rejected for the same reason: a revision moves when mail ARRIVES too, and
in neither case does it say anything about the server.

What was actually wrong was the reporting channel. The application
inferred a finished run from an inode in /proc/locks and from grepping
the log for its RUN END banner, which made a human-readable line into
wire format and could not say WHICH channels a run carried. The local
sync path has always narrowed its clear to the accounts it carried; the
external path could not, and cleared everything, so an edit to an
account a run never touched was reported as delivered.

So the script reports instead of leaving evidence to be inferred. It
writes ~/.local/state/qtmaildir/syncstatus.json atomically at the end of
every run, including a skip, naming the channels, both exit statuses and
a state of ok, failed or skipped. MailSync::readStatus() reads it,
MainWindow prefers it over the log banner and narrows the clear through
Account::syncChannel(). A skipped run clears nothing, which is item 125's
first half: the application can now see that a run happened and carried
nothing. The log banner and lastRunOutcome() stay as the fallback for a
missing file, which is what a first run after upgrading looks like.

This is the user's own framing of the scope: the script was written for
another system and adapted, and is now qtmaildir's only consumer, so it
serves the application rather than the reverse. Two facts made it safe to
act on: their crontab runs mailsync.sh and nothing else touches mail, and
~/bin/mailsync.sh is a symlink into this repo, so an edit is live on the
next tick.

Two bugs found while wiring it in, both recorded in the closed item.

A test read the developer's real sync state, twice: a [sync] section
naming only `log` leaves syncStatus() defaulting to the real file, so two
tests asserting that a FAILED run leaves the count alone read the last
real cron run, found ok, and cleared. Pinning only `status` has the
mirror problem. noSyncTestReadsTheRealSyncState() is the guard, modelled
on noTestCanSeeTheRealLockTable().

And Qt::ISODate carries no milliseconds. The status file is preferred
only when it describes THIS run, compared against when the lock appeared,
so a stale success cannot outrank a fresh failure; but the script writes
date -Iseconds, and a round trip of "now" comes back 329 ms behind,
measured. A fast sync's own file therefore parsed as stale and fell back
to the log, with nothing failing to say so. One second of slack matches
the precision the format carries.

Design: docs/superpowers/specs/2026-08-29-sync-status-file-design.md

Suite: 43 of 44, with undoMovesTheMessageBack failing as it does on
master (item 136).

1 files changed, 67 insertions, 10 deletions

diff --git a/src/mainwindow.cpp b/src/mainwindow.cpp
index 1da9ac7..01c0251 100644
--- a/src/mainwindow.cpp
+++ b/src/mainwindow.cpp
@@ -5089,6 +5089,10 @@ void MainWindow::onExternalSyncStateChanged(SyncMonitor::State state)
             return;
 
         m_externalSyncBusy = true;
+        // When this run began, so the status file it leaves can be told from
+        // one an earlier run left (item 174). A stale file must not be read as
+        // this run's result.
+        m_externalSyncStartedAt = QDateTime::currentDateTime();
         updateSyncControls();
         m_statusLabel->setText(tr("Background sync running..."));
         m_announcedExternalSync = true;
@@ -5174,12 +5178,54 @@ void MainWindow::onExternalSyncStateChanged(SyncMonitor::State state)
         // Without this the indicator kept reporting work that had already
         // shipped, and the exit prompt asked to sync for it.
         //
-        // The outcome comes from the RUN END line the script writes, because
-        // the process that ran this sync is gone and its exit status with it.
-        // Anything other than a definite OK changes nothing: the local path's
-        // rule is that only a SUCCESSFUL sync may clear the count, and Unknown
-        // is the absence of evidence rather than evidence of success.
-        if (MailSync::lastRunOutcome(m_config.syncLog()) == SyncOutcome::Ok) {
+        // The process that ran this sync is gone and its exit status with it,
+        // so what it did has to be read from what it left behind.
+        //
+        // Item 174: the status file the script writes, which says which
+        // CHANNELS the run carried. The RUN END line in the log remains the
+        // fallback for a status file that is missing or unreadable, which is
+        // what a first run after upgrading looks like; it cannot name channels,
+        // so that path keeps the old blanket clear.
+        //
+        // Anything other than a definite success changes nothing, on either
+        // path: the local rule is that only a SUCCESSFUL sync may clear the
+        // count, and Unknown is the absence of evidence rather than evidence of
+        // success. A SKIPPED run is neither, and clears nothing: the other run
+        // is doing the work and this one carried none of it.
+        // The status file is preferred, but only when it describes THIS run.
+        // A stale one outranking a fresh log would be worse than not having it:
+        // an old success would clear the count for a run that has just failed,
+        // which is the indicator lying in the direction that loses work.
+        //
+        // "This run" is judged on the file being at least as new as the sync
+        // that just ended. m_externalSyncStartedAt is when the lock appeared,
+        // and the script writes the file immediately before exiting, so a file
+        // older than that belongs to an earlier run.
+        const SyncStatus status = MailSync::readStatus(m_config.syncStatus());
+
+        // The script writes `date -Iseconds`, which carries no milliseconds, so
+        // a file written in the same second as the lock appeared parses as up
+        // to 999ms EARLIER than it. Measured: an ISODate round trip of "now"
+        // comes back 329ms behind. A plain `>=` therefore judges a fast sync's
+        // own status file stale and falls back to the log, which is the
+        // opposite of the intent.
+        //
+        // One second of slack, matching the precision the format actually
+        // carries. This cannot readmit a genuinely stale file: cron runs ten
+        // minutes apart, and a run whose file is a second old IS this run.
+        constexpr qint64 kTimestampSlackMs = 1000;
+        const bool statusIsForThisRun =
+            status.state != SyncState::Unknown
+            && (!m_externalSyncStartedAt.isValid() || !status.ended.isValid()
+                || status.ended.msecsTo(m_externalSyncStartedAt)
+                       <= kTimestampSlackMs);
+
+        const bool carried =
+            statusIsForThisRun
+                ? status.carriedEdits()
+                : MailSync::lastRunOutcome(m_config.syncLog()) == SyncOutcome::Ok;
+
+        if (carried) {
             m_pendingTagEdits.clear();
 
             // Cleared HERE, before flushHeldEdits() below, and the ordering is
@@ -5188,10 +5234,21 @@ void MainWindow::onExternalSyncStateChanged(SyncMonitor::State state)
             // writes m_editedAccounts SYNCHRONOUSLY. Clearing after the flush
             // would discard accounts whose edits this run did not carry, and
             // those edits would then sync only when some later edit happened to
-            // name the same account. Running first, everything in the set at
-            // this moment is exactly what the finished sync carried, so the
-            // local path's snapshot-and-subtract collapses to a clear.
-            m_editedAccounts.clear();
+            // name the same account.
+            //
+            // WHICH accounts, when the status file said. A run naming channels
+            // carried those and no others, so clearing the whole set would
+            // report an untouched account's edits as shipped. `-a` and the log
+            // fallback both mean every account, where the blanket clear is
+            // right.
+            if (!status.everyChannel && !status.channels.isEmpty()) {
+                for (const Account &account : m_config.accounts()) {
+                    if (status.channels.contains(account.syncChannel()))
+                        m_editedAccounts.remove(account.key);
+                }
+            } else {
+                m_editedAccounts.clear();
+            }
             updatePendingIndicator();
         }
     }