docs: specify the thread pane as a card list

Item 53 recorded that message rows read as a table and left the approach
unspecified, with four directions ranging from spanning columns on reply rows to
abandoning message rows entirely. The user's answer is wider than all four: the
column grid is wrong for the WHOLE left pane, threads included.

Threads and replies both become cards in a single column, three lines each, at
one uniform height. Sender and date, then the subject with the flag, attachment
and reply-count marks inline, then the tag chips. Replies indent by depth with a
continuous spine, capped at depth 4.

Three decisions worth their reasoning, since each closed an option that looked
cheaper:

  - Uniform height keeps setUniformRowHeights(true), which is the single
    cheapest property of the design. A blank third line under untagged cards
    buys constant sizeHint arithmetic everywhere else.
  - Uncapped indent with a horizontally scrollable pane was asked for and
    rejected: it reopens item 51 in a worse form. Cards are viewport width, so
    the pane has no horizontal scroll range at all, and item 51 is resolved for
    free rather than fought.
  - A reply's line 3 shows only the tags its thread does not have. The full
    per-message set was rejected on measurement, not taste: of 48691 messages in
    the user's database, 7 carry unread and 75 carry flagged, and both are
    already shown as the sender's weight and the mark on line 2. Everything else
    is applied per thread and identical on every message in it, so full sets
    would render blank on nearly every reply and identical chips on the rest.

The design is a net removal. ThreadListView::paintEvent, the tag strip's band
arithmetic, SubjectDelegate, RowStyleDelegate, the five Column enumerators and
the decorative header all go; one CardDelegate paints the whole card. That
retires the two bug classes CLAUDE.md documents for the strip, a deleted row cut
in half and every other row showing a bare stripe, both of which existed because
the strip spanned cells it did not own.

The column header was decorative, so a sort dropdown adds a feature rather than
replacing one. Two entries only, newest and oldest, passed to notmuch. Sorting
by sender or subject would have to happen in the model after results arrive,
which fights the batching that makes a 10k-thread query paint immediately.

Item 51 is marked resolved by 53 rather than left as separate work.

1 files changed, 18 insertions, 4 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 159643f..c799e23 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
@@ -108,9 +108,9 @@ taking that too literally.
 | 48 | Removing a tag suggests every tag, not the thread's own | workflow | XS | **done** |
 | 49 | Sync runs every account regardless of what changed | workflow | M | **done** |
 | 50 | Esc blanks the pane but leaves the row selected | workflow | XS | **done** |
-| 51 | Clicking a subject scrolls the list sideways | presentation | XS | open |
+| 51 | Clicking a subject scrolls the list sideways | presentation | XS | open; resolved as a side effect of 53, do not work separately |
 | 52 | `test_querycompleter` fails under Wayland, passes offscreen | testing | XS | **done** |
-| 53 | Message rows still read as a table, not as a conversation | presentation | ? | open, unspecified |
+| 53 | Message rows still read as a table, not as a conversation | presentation | M | open, specified 2026-08-09; see the card-list spec |
 | 54 | A cron sync carries the edits but the count still says pending | correctness | S | **done** |
 | 55 | In a narrow window the message pane is invisible | presentation | XS | **done** |
 | 56 | No action carries an icon, so the toolbar reserves space for nothing | presentation | S | **done** |
@@ -3241,8 +3241,22 @@ exists, and its band arithmetic assumes a uniform row height and a known column
 layout. Anything that varies row height or removes columns for one row kind has
 to answer for the strip on thread rows, which must not change.
 
-**Do not start any of these from this description.** It says what is and why,
-not what was wanted.
+**Specified 2026-08-09.** The user's answer was that the grid is wrong for the
+WHOLE left pane, not only for reply rows, which is wider than any of the four
+directions above. Threads and replies both become cards in a single column, with
+no column grid at all. The design is at
+`docs/superpowers/specs/2026-08-09-card-list-design.md`; read that rather than
+this entry, which records only the finding.
+
+Two things settled here that the directions above got wrong. Direction 2's `Re:`
+prefix removal is folded in rather than tried first, since the grid goes anyway.
+And the constraint about the tag strip inverts: the strip is not something the
+design has to answer for, it is deleted, because `ThreadListView` exists ONLY to
+paint across columns that no longer exist. This item is a net removal of code.
+
+**Item 51 is resolved by this design as a side effect** and should not be worked
+separately. Cards are exactly viewport width, so the pane has no horizontal
+scroll range for a click to scroll into.
 
 ## 54. A cron sync carries the edits but the count still says pending