docs: record message rows, and the user's verdict on them

CLAUDE.md described a QTableView over a table model, which has not been true
since the view port. Updated with the traps the port produced, each of which
shipped a plausible-looking broken build before being caught:

  - A tree numbers rows per parent, so nothing may be keyed on a row NUMBER.
  - drawBranches runs before the row's cells, so an expander on a content
    column is painted over by the delegate's background.
  - setRootIsDecorated(false) removes the style's HIT AREA along with its
    indicator, leaving a glyph that renders and does nothing.
  - isExpanded and setExpanded are keyed on column 0.
  - A reply's indent must beat the account chip's width, and visualRect
    reports the indent correctly even when nothing is visibly indented.
  - paintEvent runs after the cells, so a full-row fill erases their text.

Also the notmuch ownership rule, which is a double-free if undone: messages
reached through a thread are freed with it, so walkReplies holds them raw
against this file's own RAII convention.

Item 20 is marked built, not done, and item 53 records why. The user's verdict
on the finished result was that the table view does not fit the use, said with
every cue in and working. That is a design finding rather than a defect: the
item shipped exactly what its four decisions specified, and all four were the
user's own choices. Recording it as a defect would misattribute the cause;
recording nothing would leave the next session building on a rejected design.

Item 53 carries the cause verified in code rather than guessed. A message row
fills the same five columns as a thread row (threadlistmodel.cpp:275-283
mirroring :428-431), so replies land on the same rigid column boundaries as the
threads around them, and the eye reads columns before indentation or tint. The
reference the user gave has no column rules through its reply rows at all, and
that absence is the one thing three added cues cannot supply.

0 files changed, 0 insertions, 0 deletions