feat(ui): scope actions to the selected row kind and name it

tagSelected resolved rows to threads with threadAt(index.row()), which is wrong
for a message row: a child's row number indexes its siblings, so acting on a
reply tagged whichever thread sat at that position in the list. It now routes
through ThreadListModel::scopeFor, and a message row's change is sent as message
ids down applyTags with its own MessageTagCommand for undo.

MessageTagCommand stores message ids where ThreadTagCommand stores thread ids,
and that difference is the point rather than an inconsistency: re-resolving the
thread on undo would restore tags across every sibling the action never touched.

sendMessageTagChange deliberately skips the optimistic model update.
applyTagChange is keyed by thread and would repaint the whole row as though
every message in it had changed, which for a one-message edit is a lie the user
watches correct itself on the next query. It keeps the two things that are NOT
optional: the edited-account set, resolved through the containing thread since
the account is a property of the thread, and holding the edit when a sync holds
notmuch's write lock, since the worker's read-write open blocks rather than
failing.

The scope is now stated before an action and after it, naming both the message
count and whether a whole thread went. This is what stands in for the
confirmation dialog CLAUDE.md rules out: undo is the safety net, and undo is
only usable if the user can tell that something larger than they meant has just
happened. Selecting a single message reports no count at all, since reading one
message is not a bulk action.

A mutation that routed message rows down the thread path SURVIVED the whole
suite: undo depth and status text are identical either way while every sibling
gets tagged. anActionOnAMessageRowTagsThatMessageNotTheThread exists because
that gap was found, and asserts on the ids actually sent.

anActionOnAThreadRowSaysItHitTheWholeThread reads the status bar BEFORE draining
the event loop. This binary has no worker, backlog item 36, so the queued write
reaches a database that has never heard of the thread and answers with
errorOccurred, which overwrites the status bar: draining first asserts on that
error and fails against correct code.

1 files changed, 65 insertions, 0 deletions

diff --git a/src/mainwindow.h b/src/mainwindow.h
index 5b7e39e..90cfd8f 100644
--- a/src/mainwindow.h
+++ b/src/mainwindow.h
@@ -129,6 +129,19 @@ public:
     /// command was pushed, which is what "this did nothing" has to assert.
     int undoDepthForTesting() const { return m_undoStack.count(); }
 
+    /// The ids the last tag change was sent for, and whether they were thread
+    /// ids or message ids.
+    ///
+    /// Exposed because the difference is invisible from outside otherwise: a
+    /// message row routed down the thread path produces the same undo depth and
+    /// the same status text while tagging every sibling in the thread. A
+    /// mutation that made exactly that change passed the whole suite.
+    QStringList pendingThreadIdsForTesting() const { return m_pendingThreadIds; }
+    QStringList pendingMessageIdsForTesting() const
+    {
+        return m_pendingChange.messageIds;
+    }
+
     /// The generation a worker reply must carry to be accepted.
     ///
     /// A test seam: onQueryFinished() discards a reply whose generation is
@@ -351,6 +364,13 @@ private:
                              const QStringList &remove,
                              const QString &description);
 
+    /// The same for individual MESSAGES, without touching the undo stack.
+    /// Both tagSelected() and MessageTagCommand route through this.
+    void sendMessageTagChange(const QStringList &messageIds,
+                              const QStringList &add,
+                              const QStringList &remove,
+                              const QString &description);
+
     /// Undoes the optimistic model update for a write the worker rejected.
     void revertPendingTagChange();
 
@@ -384,6 +404,7 @@ private:
     QVector<HeldEdit> m_heldEdits;
 
     friend class ThreadTagCommand;
+    friend class MessageTagCommand;
 
     Config m_config;
     KeyMap m_keyMap;
@@ -615,3 +636,47 @@ private:
     QString m_description;
     bool m_firstRedo = true;
 };
+
+/// Undo entry for a tag change over individual MESSAGES.
+///
+/// Stores message ids, unlike ThreadTagCommand, and that difference is the
+/// point rather than an inconsistency: a message row acts on one message, so
+/// re-resolving its thread on undo would restore tags across every sibling the
+/// action never touched.
+class MessageTagCommand : public QUndoCommand
+{
+public:
+    MessageTagCommand(MainWindow *window, const QStringList &messageIds,
+                      const QStringList &add, const QStringList &remove,
+                      const QString &description)
+        : QUndoCommand(description), m_window(window),
+          m_messageIds(messageIds), m_add(add), m_remove(remove),
+          m_description(description) {}
+
+    /// The stack calls redo() when the command is pushed, by which point the
+    /// change has already been sent, so the first call is skipped.
+    void redo() override
+    {
+        if (m_firstRedo) {
+            m_firstRedo = false;
+            return;
+        }
+        m_window->sendMessageTagChange(m_messageIds, m_add, m_remove,
+                                       m_description);
+    }
+
+    void undo() override
+    {
+        m_window->sendMessageTagChange(
+            m_messageIds, m_remove, m_add,
+            QStringLiteral("Undo %1").arg(m_description));
+    }
+
+private:
+    MainWindow *m_window;
+    QStringList m_messageIds;
+    QStringList m_add;
+    QStringList m_remove;
+    QString m_description;
+    bool m_firstRedo = true;
+};