docs: record item 119 and close it in the backlogHEADmaster

The status rows for 119 and its duplicate 146, 119's section moved to the
closed file on this commit rather than left for a later cleanup, and the
README and changelog entries for the feature.

CLAUDE.md gains three findings, all of which cost time to learn here:

A defensive counter for an unreachable case is worse than nothing, because
it blocks the feature that needs the data. Reading the code said that branch
was reachable and the reading was wrong; instrumenting it and running the
suite is what settled it, and the tests that appeared to exercise it were
driving it from outside the production path.

PendingChangesDialog groups by a run rather than a map, which is why the
snapshot is stable-sorted, and startsMessage is carried rather than inferred
so a stale row still opens its own run.

A queued call carrying a container deserves the same suspicion as a Q_ENUM,
with the measurement: both containers cross intact on Qt 6.11, but a
standalone probe found QMetaType::fromName("QList<int>") invalid while
QList<bool> resolved, so the property does not follow from the type.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P88Q3MCSCSQxKDy7pmXh9F

1 files changed, 11 insertions, 0 deletions

diff --git a/README.md b/README.md
index 70df5ca..4ae0034 100644
--- a/README.md
+++ b/README.md
@@ -691,6 +691,17 @@ that a sync has not yet carried over, and clears the count when one succeeds. A
 **failed** sync leaves the count standing, since the changes really are still
 unsynced.
 
+**Click the count to see what it holds.** The list names each message with
+the actions waiting on it beneath it, so a message you tagged twice appears
+once with both. An action taken on a whole thread is one entry, saying how
+many messages it covers, because that is what you asked for; an action on a
+single message names that message, whether or not it sits in a thread.
+
+The list is read-only, and it is a snapshot taken when you open it: it does
+not rewrite itself while you read it. A change whose message has since left
+the index is still listed, saying so, rather than quietly disappearing, so
+the number you clicked always matches the number of entries you get.
+
 The count is a lower bound rather than a guarantee: an external `notmuch new`
 from your own cron can carry changes over without this application noticing.