fix(ui): expand flat threads, reach the first message, localise the date

Four faults from the first hand test, two of them behavioural.

An expander that opened onto nothing. setThreadMessages kept only nodes with
depth > 0, and notmuch_thread_get_toplevel_messages returns every message at
depth 0 when a thread carries no usable In-Reply-To, so a flat thread
contributed no children while its card still advertised the count. Measured in
the user's database: of 396 inbox threads three are flat, one of them nine
messages long, and every two-message thread of that kind was affected, which is
exactly why the fault looked like "the expander only works with more than one
reply". The rule is now position, not depth: every message except the first,
which is the root card itself. That is also the correct rule rather than a
workaround, since the row under the root is the second message however notmuch
chose to nest it.

The thread's first message was unreachable. Selecting a root card loaded the
whole thread, so the pane showed every message with only the last expanded, and
no row in the list offered the first one: the reply rows are messages two
onward. The root card now renders its own message, which is what the card
already claims to be. It keeps its thread id, unlike the message-row path, so
mark-read and the tag-change repaint still work; that is asserted, because
clearing it is the obvious way to write this and silently disables both. Before
the replies are loaded the model has no first message to name and the whole
thread stays the honest answer.

Dates ignored the locale. One hardcoded "yyyy-MM-dd hh:mm" produced a US-looking
format on an Italian desktop; QLocale::system() now formats it, and the width
reserved for the date comes from the same function so a longer locale cannot
clip.

The expander was a bare number on the card's own background. It is a pill now,
carrying "3 replies" (and "1 reply", singular), sized from the label actually
drawn and measured in both glyph states so it does not resize under the pointer
on click. Its fill is blended from Text toward Base rather than taken from
QPalette::Button, which is #2b2b2b against a Base of #2b2b2b on the user's
theme: byte identical, so the pill was invisible. A theme may make any two roles
equal; a blend is defined against the surface it sits on and cannot collide with
it. Checked by rendering both a dark and a light palette and looking.

1 files changed, 28 insertions, 9 deletions

diff --git a/src/threadlistmodel.cpp b/src/threadlistmodel.cpp
index d8412f9..bdc7e96 100644
--- a/src/threadlistmodel.cpp
+++ b/src/threadlistmodel.cpp
@@ -365,8 +365,13 @@ QVariant ThreadListModel::data(const QModelIndex &index, int role) const
     if (role == IsMessageRole)
         return false;
 
-    if (role == MessageIdRole)
-        return QString();
+    if (role == MessageIdRole) {
+        // The thread's FIRST message, once known, because the root card is
+        // that message: selecting it renders one message rather than the whole
+        // conversation. Empty before the replies are loaded, which is the
+        // caller's signal to load the thread instead of guessing at a message.
+        return m_threads.at(index.row()).first.messageId;
+    }
 
     if (role == MessageDepthRole)
         return 0;
@@ -542,7 +547,7 @@ void ThreadListModel::appendBatch(const QVector<ThreadSummary> &batch)
     const int first = m_threads.size();
     beginInsertRows({}, first, first + batch.size() - 1);
     for (const ThreadSummary &summary : batch)
-        m_threads.append(ThreadNode{ summary, {}, false });
+        m_threads.append(ThreadNode{ summary, {}, {}, false });
     endInsertRows();
 }
 
@@ -570,12 +575,26 @@ void ThreadListModel::setThreadMessages(const QString &threadId,
             endRemoveRows();
         }
 
-        QVector<MessageNode> children;
-        children.reserve(nodes.size());
-        for (const MessageNode &node : nodes) {
-            if (node.depth > 0)
-                children.append(node);
-        }
+        // Every message EXCEPT the first, which is the root card itself.
+        //
+        // Selecting on depth > 0 instead was wrong, and wrong in a way that
+        // only showed on real mail: notmuch_thread_get_toplevel_messages
+        // returns every message at depth 0 when a thread carries no usable
+        // In-Reply-To, so a flat thread contributed no children at all. The
+        // card advertised "3 replies" and expanded onto nothing. Measured in
+        // the user's database: of 396 inbox threads, three are flat, one of
+        // them nine messages long, and every two-message thread of this kind
+        // was affected, which is why the fault looked like "the expander only
+        // works with more than one reply".
+        //
+        // Position also happens to be the right rule rather than a workaround.
+        // The root card IS the thread's first message, so the row under it is
+        // the second message whatever depth notmuch assigns it.
+        QVector<MessageNode> children = nodes.mid(1);
+
+        // Kept so the root card can render its own message. It is the card the
+        // user clicks to read the thread's opening message.
+        m_threads[row].first = nodes.isEmpty() ? MessageNode() : nodes.first();
 
         if (!children.isEmpty()) {
             beginInsertRows(parent, 0, children.size() - 1);