fix(sync): send held edits before the sync-end refresh reads the database

An edit made while a sync is running is held rather than sent, because the
worker's read-write open blocks on notmuch's exclusive lock. At sync end
onExternalSyncStateChanged() refreshed the list first and flushed the held
edits afterwards, so the refresh read a database that still carried the old
tag, reconciled it into the model, and overwrote the optimistic update the hold
had deliberately left applied. The flush then wrote the tag correctly.

The database ended up right and the list ended up wrong, with nothing scheduled
to re-read it, which is why it looked like the edit had been lost. Reported by
hand: a message read during a sync went back to unread when the sync finished.

The flush moves ahead of the refresh and keeps both properties it already had.
It stays outside the Idle branch, so edits held when /proc/locks becomes
unreadable are not stranded waiting for an Idle that never comes, and it stays
after the status-bar retire, so its own "N held changes sent" message survives.

Both orders leave identical end state, so the first version of the test passed
against the defect: after the handler returns the queue is empty and the write
has been sent whichever ran first. flushGenerationForTesting() stamps the query
generation at flush time, which is what separates them, and the test fails
against the old order with Actual: 3, Expected: 2.

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

1 files changed, 5 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 816f03b..61a96bd 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,6 +24,11 @@ point at which they are stable.
   pending until a manual sync or the next cron run. It now re-arms at the
   configured delay. Skipping a concurrent run is unchanged: two mbsync runs
   cannot share the lock.
+- A tag change made while a sync was running reappeared undone in the thread
+  list when that sync finished. The change was held until the sync released
+  notmuch's write lock, but the list was refreshed from the database before the
+  held change was written to it, so the refresh painted the old tag back. The
+  change itself was never lost, only the list was wrong.
 
 ## [0.23.0] - 2026-08-15