fix(sync): clear the pending-edit count on a cron sync

Item 54. A sync fired by the user's cron carries tag edits to the mail
store exactly as a local one does, but only onSyncFinished() cleared the
pending state, so the indicator kept reporting work that had already
shipped and the exit prompt asked to sync for it. Verified against a
real cron run: 31 changes, cleared with no manual sync.

The window cannot see an external run's exit status, and /proc/locks
carries no outcome. It does not need to: mailsync.sh already ends every
run with a "RUN END ... status=OK" banner in its log, which outlives the
process that wrote it. MailSync::lastRunOutcome() reads a bounded tail
of that file and takes the last completed marker, so no change to the
script and no optimistic guessing were needed.

Only a definite OK clears anything. A failed run, a missing or
unreadable log, and a State::Unknown lock reading all leave the count
alone: over-reporting costs a redundant sync, under-reporting costs the
user their edits.

m_editedAccounts is drained in the same place, before flushHeldEdits()
and matching the local path's ordering. Item 49 uses it to choose which
mbsync channels a run syncs, and a count that reached zero while the set
stayed full would look correct and still sync the wrong channels.

The log path comes from a new optional [sync] log key, defaulting to
where the script writes, so a test never reads the developer's own log.

Two notes on the verification, both recorded in the backlog:

  - A timing probe endorsed a tail read that was not happening. The
    first version of the huge-log test required the call under 100 ms
    and passed with the seek deleted, because reading 10 MB is fast
    either way. Replaced with an assertion on content.

  - Every fixture was invented and the first batch had the wrong
    timestamp format, since the script uses date -Iseconds. The tests
    passed anyway, because the parser keys on the prefix and the status
    token. One test now builds the banner the way the script does.

The before-flushHeldEdits ordering has no test: without a held lock the
flush is a no-op, so both orderings pass.

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

1 files changed, 9 insertions, 2 deletions

diff --git a/src/mainwindow.h b/src/mainwindow.h
index 2d41b5e..490467f 100644
--- a/src/mainwindow.h
+++ b/src/mainwindow.h
@@ -325,7 +325,11 @@ private:
 
     /// Sends a tag change for a set of threads without touching the undo stack.
     /// Both tagSelected() and ThreadTagCommand route through this.
-    void sendThreadTagChange(const QStringList &threadIds,
+    ///
+    /// Invokable so a test can record an edit against a known account without a
+    /// worker: this is where m_editedAccounts is populated, and item 54's
+    /// draining of it cannot be observed otherwise.
+    Q_INVOKABLE void sendThreadTagChange(const QStringList &threadIds,
                              const QStringList &add,
                              const QStringList &remove,
                              const QString &description);
@@ -543,7 +547,10 @@ private:
     /// The channel names for m_editedAccounts, resolved through the config.
     /// Empty means sync everything, which is what a fetch with nothing pending
     /// has to do.
-    QStringList pendingSyncChannels() const;
+    /// Invokable for the same reason as sendThreadTagChange(): it is the only
+    /// view onto m_editedAccounts, and a count that reaches zero while the set
+    /// stays full looks correct and still syncs the wrong channels.
+    Q_INVOKABLE QStringList pendingSyncChannels() const;
 };
 
 /// Undo entry for a tag change over a set of threads.