fix: refresh the conversation dashboard after a write

Item 181, from the user's notes: "the thread dashboard doesn't update
live with the modifications applied to the list pane. If I mark the
thread as read, the dash still reports N unread".

ThreadDashboard draws a ThreadDigest, which the worker builds from the
index and which reached the pane only when a conversation was selected.
A tag write updated the model optimistically and repainted the card
beside it, and nothing touched the digest, so the pane went on reporting
the unread count, the progress bar and the Waiting-for-you list the
conversation had when it was opened.

Reachable from the dashboard's own Mark all read button, which is the
worst version of it: the number sits directly above the button that
fails to move it.

refreshDashboardDigest() re-asks the worker for the digest of the
conversation on display, and returns at once when the pane is showing
anything else. It bumps m_digestGeneration like any other request, so
the guards in onThreadDigestLoaded() discard a reply that arrives after
the user has moved on. No placeholder digest, unlike the selection path:
the pane already holds this conversation, and blanking it to re-fill it
would flicker the whole dashboard for a change to one number.

Called from onTagsApplied(), where a write is CONFIRMED, and not from
the two write funnels. The first attempt put it beside the optimistic
model update by analogy with every other optimistic repaint, and that
analogy does not hold here: the digest is rebuilt from the index, so a
refresh queued beside the write reaches the worker before the write does
and answers from the state before it. The test failed identically to no
fix at all.

Every write rather than a chosen subset, at the user's decision:
narrowing it to the writes that change what the dashboard happens to
draw today is a list the dashboard can outgrow silently, and this costs
a round trip only while a conversation is on screen. Re-requested rather
than edited in place, because the digest is a derived summary and
recomputing it here would be a second place that has to agree with the
worker about what a write did.

The test is worker-backed over a real two-message conversation and is
driven through the mark_all_read action rather than the private funnel,
which is the path the dashboard's own button takes. It asserts the pane
carries the unread state before the write, so the assertion after it
means something.

Suite: 42 of 43, with undoMovesTheMessageBack failing as it does on
master (item 136).

1 files changed, 6 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 34d9d2e..cf7082d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -143,6 +143,12 @@ point at which they are stable.
 
 ### Fixed
 
+- **The conversation dashboard now follows what you do to the conversation.**
+  Marking a thread read left the pane reporting the unread count, the progress
+  bar and the "Waiting for you" list it had when you opened it, including when
+  the write came from the dashboard's own Mark all read button, where the
+  number sits directly above the button that failed to move it. Every tag
+  write to the conversation on display now refreshes it.
 - **Delete and Restore now judge a whole conversation.** They asked whether a
   row was in the trash by looking at one of its messages, so a conversation
   with some messages trashed and some not answered on whichever the query