feat(message): show From/To/Cc and add a details dialog

MimeParser has filled To and Cc all along and HtmlBuilder simply never
interpolated them, so both were parsed on every message and then
discarded. The header strip showed the subject and a message count and
nothing else, which is item 2 of the usability backlog.

The header now adapts to what it can say honestly. A thread holding one
message shows From, To and Cc under the subject, where every field is
unambiguous. A thread holding several keeps showing the subject and the
count alone: the recipient differs message to message, and once the user
has replied there is no single address the thread is addressed to, so
naming one would be a guess presented as a fact. Per-message detail is
what the dialog is for.

That dialog lists Subject, From, To, Cc, Date and Message-Id for every
message, numbered when there is more than one, in a read-only plain-text
widget. Plain text is the security decision, not a stylistic one: these
values come from strangers and the dialog exists to show them verbatim,
so the format that cannot interpret markup is the right one. The header
label is RichText and every value interpolated into it is escaped, since
an unescaped From injects into the application's own chrome rather than
into the sandboxed page.

Reached by a Details... button beside the subject and by Ctrl+Shift+D.
Both, because a shortcut alone restates the complaint this backlog opened
with. The binding is shifted because Ctrl+D is delete, and the
destructive action keeps the key it already had rather than being moved
to make room.

An empty Cc omits its row instead of printing a label with nothing after
it. Both header shapes were rendered to PNG and inspected, not only
asserted.

The new button also exposed a latent flaw in an older test:
attachmentButtonLabels() identified attachment buttons by excluding the
one other button's label, so it counted the details button as an
attachment as soon as one existed. It now finds the bar by object name
and reads only its children.

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

1 files changed, 32 insertions, 1 deletions

diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index e945aeb..35d5937 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -41,7 +41,7 @@ taking that too literally.
 | # | Item | Cluster | Size | Status |
 |---|------|---------|------|--------|
 | 1 | Splitter/column widths do not survive restart | persistence | S | **done** |
-| 2 | No way to see full message details (From/To/Cc/Subject) | information | M | open |
+| 2 | No way to see full message details (From/To/Cc/Subject) | information | M | **done** |
 | 3 | Too few clickable affordances, shortcuts are the only route | discoverability | M | **done** |
 | 4 | Message-pane font size does not survive restart | persistence | S | **done** |
 | 5 | Thread list is cramped, poor readability | presentation | S | open |
@@ -188,6 +188,12 @@ to compute they can be displayed as they stand. Splitting them into address
 lists, which would have needed GMime's `internet_address_list_parse` to survive
 a display name containing a comma, is not part of this item.
 
+**Deferred, not rejected (user, 2026-08-04): a participants line for threads.**
+The union-of-recipients idea is worth revisiting as its own pass, where it can
+be designed as a participants list rather than smuggled in under a "To:" label
+that misdescribes it. It needs the address parsing above, so it is a genuine
+piece of work rather than a display tweak. Build this item as specced first.
+
 **Noted for later, not now:** the user's mental model of the thread view
 differs from what was built. That is a separate refactor and should not be
 folded into this item.
@@ -199,6 +205,31 @@ does. A `From` display name containing markup must never be able to inject into
 the label. The raw-header dialog should use `Qt::PlainText` and sidestep the
 question entirely.
 
+### Outcome (done)
+
+Built as decided. `MessageView::updateHeader()` branches on the item count: one
+message shows From, To and Cc under the subject, several show the subject and
+the count exactly as before. `showDetailsDialog()` lists every message's
+Subject, From, To, Cc, Date and Message-Id, numbered when there is more than
+one, in a read-only `QPlainTextEdit`. A `Details...` button sits to the right of
+the header, and `message_details` binds it to `Ctrl+Shift+D` (shifted because
+`Ctrl+D` is delete, and the destructive binding keeps the key it had).
+
+- **Rendered and inspected**, not only asserted: both header shapes were grabbed
+  to PNG and looked at. The single-message case shows three rows under the
+  subject, the thread case shows the count and no recipients.
+- **An empty Cc omits its row** rather than printing a label with nothing after
+  it, which reads as a rendering fault.
+- **A test caught a latent flaw in an older test.** `attachmentButtonLabels()`
+  identified attachment buttons by excluding the one other button's label, so
+  the new details button was counted as an attachment the moment it existed.
+  It now finds the bar by object name and looks only at its children, which is
+  what it should have done: an exclusion list silently adopts every button
+  added later.
+
+**No address parsing was needed**, as the decision above anticipated. The header
+prints `ParsedMessage::to` and `::cc` as they stand.
+
 ## 3, 8, 9. Discoverability: menu bar, toolbar, shortcut reference
 
 Grouped because they are one piece of work. Item 3 is the complaint, items 8