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).

2 files changed, 49 insertions, 0 deletions

diff --git a/src/mainwindow.cpp b/src/mainwindow.cpp
index eb8f4c6..df7062d 100644
--- a/src/mainwindow.cpp
+++ b/src/mainwindow.cpp
@@ -4215,6 +4215,25 @@ void MainWindow::onThreadSelected(const QModelIndex &current,
                               Q_ARG(quint64, m_generation));
 }
 
+void MainWindow::refreshDashboardDigest()
+{
+    // Not showing a conversation: the ordinary case, and nothing to refresh.
+    if (m_dashboardThreadId.isEmpty() || !m_messageView->showingDashboard())
+        return;
+
+    // No placeholder digest here, unlike the selection path: the pane is
+    // already showing this conversation, and blanking it to re-fill it would
+    // flicker the whole dashboard for a change to one number.
+    //
+    // Its own generation, bumped like any other request so a reply that
+    // arrives after the user has moved on is discarded by the guards in
+    // onThreadDigestLoaded().
+    ++m_digestGeneration;
+    QMetaObject::invokeMethod(m_worker, "loadThreadDigest", Qt::QueuedConnection,
+                              Q_ARG(QString, m_dashboardThreadId),
+                              Q_ARG(quint64, m_digestGeneration));
+}
+
 void MainWindow::onThreadDigestLoaded(const ThreadDigest &digest,
                                       quint64 generation)
 {
@@ -4710,6 +4729,12 @@ void MainWindow::onTagsApplied(const TagChange &change)
     m_pendingChange = {};
     m_pendingThreadIds.clear();
 
+    // Item 181. HERE, where a write is CONFIRMED, and not where one is sent:
+    // the digest is rebuilt from the INDEX, so a refresh queued beside the
+    // write would race it and answer from the state before it. The dashboard
+    // covers every write for the same reason the indicator below does.
+    refreshDashboardDigest();
+
     // Item 176. The ids the worker reports are the ones whose tags really
     // moved, which is what the undo entry has to invert. Inverting the REQUEST
     // instead turned the undo of "mark 44 read" into "mark 44 unread": 2
diff --git a/src/mainwindow.h b/src/mainwindow.h
index d7579f4..1f68733 100644
--- a/src/mainwindow.h
+++ b/src/mainwindow.h
@@ -645,6 +645,30 @@ private slots:
     /// has moved off, or one that arrives once the pane is showing a message,
     /// must not repaint anything.
     void onThreadDigestLoaded(const ThreadDigest &digest, quint64 generation);
+
+    /// Re-asks the worker for the dashboard's digest, after a write that may
+    /// have changed what it draws.
+    ///
+    /// Item 181. The digest is built from the INDEX by the worker and arrived
+    /// only when a conversation was selected, so a tag write moved the model
+    /// and the card and left the pane reporting the unread count the
+    /// conversation had when it was opened. Reachable from the dashboard's own
+    /// Mark all read button, where the number sits directly above the button
+    /// that fails to move it.
+    ///
+    /// Called from BOTH write funnels, per the rule that every path a
+    /// thread-scoped write travels a message-scoped one travels too. It is
+    /// deliberately not narrowed to the writes that change what the dashboard
+    /// happens to draw today: that list is one the dashboard can outgrow
+    /// silently, and this costs a round trip only while a conversation is on
+    /// screen.
+    ///
+    /// Does nothing when the pane is not showing a dashboard, which is the
+    /// ordinary case. Re-requests rather than editing the digest in place: the
+    /// digest is a derived summary (senders, buckets, timestamps, the unread
+    /// list and its cap), and reproducing that arithmetic here would be a
+    /// second place that has to agree with the worker about what a write did.
+    void refreshDashboardDigest();
     void onWorkerError(const QString &message);
     void onSyncFinished(bool success, int exitCode);