fix(ui): tell read threads from unread without relying on bold

Bold was unread's only cue, and it renders identically to regular on the
user's system: confirmed by eye against a bare QTableView holding a
plain QStandardItemModel, with no code from this project involved. The
fault is in Qt or fontconfig, below this application, and nothing in the
model could ever have reached it. Read and unread mail looked exactly
alike.

The emphasis is inverted instead. Unread rows keep the palette's own
text colour and read rows are dimmed toward the background, so the cue
rides on Qt::ForegroundRole, which the delegate already honours, and
costs no column. It also suits the real ratio, measured at 99 unread
against 4220 read: dimming the bulk is calmer than highlighting it. The
dim colour is derived from the palette, never hardcoded, per the rule
item 12 established. Bold is kept for systems where it works, but
nothing depends on it now.

That exposed a second defect, visible the moment it shipped. Qt resolves
ForegroundRole into the palette and then prefers it over
HighlightedText, so a model-supplied colour wins on a SELECTED row too.
The dim is blended against the unselected background, so a selected read
row painted grey on the selection colour, near unreadable.
SubjectDelegate::initStyleOption now reverses that, and the delegate is
installed view-wide rather than on the subject column alone, so every
column gets the same handling instead of three of them keeping Qt's
ordering.

The guarding tests state the property rather than the mechanism: strip
the font from the model's answer and the two states must still differ.
A test asserting only that bold is set passes on a system where bold
paints like regular, which is exactly how this survived. The selection
test renders two rows identical but for the unread tag, selects both,
and requires zero differing pixels.

Part of item 5; the density work and the star column remain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 38 insertions, 5 deletions

diff --git a/src/tagchip.cpp b/src/tagchip.cpp
index 2e21419..1ac7623 100644
--- a/src/tagchip.cpp
+++ b/src/tagchip.cpp
@@ -49,6 +49,31 @@ void paint(QPainter *painter, const QRect &rect, const QString &text,
 
 }  // namespace TagChip
 
+void SubjectDelegate::initStyleOption(QStyleOptionViewItem *option,
+                                      const QModelIndex &index) const
+{
+    QStyledItemDelegate::initStyleOption(option, index);
+
+    // Qt resolves Qt::ForegroundRole into the palette's Text roles, and its
+    // own painting then prefers those over HighlightedText: a model that
+    // supplies a foreground wins even on a selected row.
+    //
+    // That is wrong for the read/unread dimming. A read thread's colour is
+    // blended against the UNSELECTED background, so over the selection
+    // highlight it lands as grey on purple, near unreadable. The highlight
+    // already says "this row", so the dimming can yield to it while selected.
+    //
+    // Doomed threads are unaffected in practice: their fill is drawn beneath
+    // the selection and their white is a contrast requirement, which
+    // HighlightedText also satisfies.
+    if (option->state & QStyle::State_Selected) {
+        const QColor highlighted =
+            option->palette.color(QPalette::HighlightedText);
+        option->palette.setColor(QPalette::Text, highlighted);
+        option->palette.setColor(QPalette::WindowText, highlighted);
+    }
+}
+
 void SubjectDelegate::paint(QPainter *painter, const QStyleOptionViewItem &option,
                             const QModelIndex &index) const
 {
@@ -87,13 +112,21 @@ void SubjectDelegate::paint(QPainter *painter, const QStyleOptionViewItem &optio
         return;
 
     painter->save();
-    // The model supplies the row's colours; honouring them keeps a deleted
-    // thread white-on-red here as everywhere else.
+    // Selection outranks the model's colour, and that order matters. A read
+    // thread carries a dimmed foreground blended against the UNSELECTED
+    // background, so painting it over the highlight leaves grey-on-purple,
+    // which is close to unreadable. The highlight already carries the "this
+    // row" signal, so the read/unread distinction can yield to it for as long
+    // as the row is selected.
+    //
+    // A doomed thread is the exception that proves the rule: its white is not
+    // a dimming but a contrast requirement against its own fill, and the fill
+    // is drawn under the selection too.
     const QVariant foreground = index.data(Qt::ForegroundRole);
-    if (foreground.isValid())
-        painter->setPen(foreground.value<QBrush>().color());
-    else if (option.state & QStyle::State_Selected)
+    if (option.state & QStyle::State_Selected)
         painter->setPen(option.palette.highlightedText().color());
+    else if (foreground.isValid())
+        painter->setPen(foreground.value<QBrush>().color());
     else
         painter->setPen(option.palette.text().color());