fix: keep bulk tag actions linear, and say when they land

Select all on a 10k-row search, then Archive, froze the window with one
CPU pinned. gdb on the live process showed the UI thread cubic before the
write was ever sent: each optimistic row write emitted dataChanged, whose
handler refreshed the action labels by walking the whole selection, and
each step of that walk looked the message up with a linear scan of every
thread.

ThreadListModel now answers id lookups from a lazily rebuilt hash,
invalidated by its own structural signals and by hand at the two in-place
id changes. MainWindow::batchModelWrites() holds the label refresh while a
loop of optimistic writes runs, then refreshes once. Two list membership
tests became sets.

The announcement also used to fade on a timer whether or not the write
had landed. It now reads "applying" until a round trip through the
worker's queue says the write has run, then "done". An error takes the
label back from a late "done".

Item 211.

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

1 files changed, 5 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 21744de..736fca0 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -39,6 +39,11 @@ point at which they are stable.
 
 ### Fixed
 
+- Acting on thousands of selected rows at once no longer freezes the window.
+  Archiving a 10k-row selection spent its time refreshing the menu labels once
+  per row, against the whole selection each time. It now does that once.
+  The status bar says an action is applying until the write has landed, then
+  that it is done, rather than letting the message fade on a timer.
 - Searching on selected text containing a double quote no longer lets the rest
   of the selection escape the query. Quotes are now doubled, which is notmuch's
   own escape; the backslash form ended the quoted term early.