docs: record the item 2 decision, postpone 10, add items 18-20

Item 2 (message details) gains the user's decision on where the details
go. The header adapts to what it can say honestly: a single-message
thread shows From, To, Cc and Subject, while a multi-message thread keeps
showing only subject and count. Everything else moves to a popup behind a
button on the right of the header.

An earlier draft also put a recipient line on the thread header, which
forced a choice between the union of recipients and their intersection
and would have needed real address parsing to compute either. The user
called that overcomplicating and dropped it, so no address parsing is
needed and the item is UI work over strings MimeParser already fills.

The item's own "check before building" question is answered in place: To
and Cc are parsed at mimeparser.cpp:344-345 and then dropped at the
renderer, which never interpolates them. The larger task it warned about
does not exist.

Item 10 is postponed at the user's request rather than dropped: the
complaint was real and the cheap first fix it proposes still stands, it
is simply not wanted now. Only its startup-query half ever shipped.

Items 18 and 19 come from the user's own notes and were missing here: a
visual cue for unsynced edits, and a sync-on-exit prompt with a config
option. 18 records a finding that shapes both: the QUndoStack looks like
a record of pending edits but is cleared on every query, so it cannot
drive the indicator and a separate counter is needed.

Item 20 records, unspecified, that the user's mental model of the thread
view differs from what was built. Nothing is designed there yet; the next
step is asking what they pictured.

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

0 files changed, 0 insertions, 0 deletions