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>

0 files changed, 0 insertions, 0 deletions