feat(config): let the date format on a card be configured

Adds [general] date_format, a QDateTime pattern for the date a thread card
shows. Absent or empty means the system locale's short format, which is what
every other application on the desktop uses and stays the default.

The format reaches the LAYOUT, not only the painter. CardLayout::compute()
reserves the date's width from widestDateSample(), so a pattern that arrived
only at the drawText call would be elided into a rect sized for the old
format, which is the clipping the bold-font fault already produced once. It
rides on CardLayout::Input and defaults to an empty string, leaving every
existing call site unchanged. Confirmed by mutation: making the width ignore
the format fails the test.

widestDateSample() memoised its result in a static, which would have sized
every format after the first from whichever arrived first. It is a plain call
now, costing one QLocale lookup per row, the same as formatting the date.

Validation rejects only a pattern whose output is CONSTANT, found by
formatting two different instants and comparing. QDateTime::toString() treats
nearly every letter as a field, so "banana" formats as "bpmnpmnpm" and
"hello" as "22ello": nonsense, but they vary with the instant, and a check
claiming to find "no date field" cannot reject them. What harms the user is
the pattern that prints the same text on every card, and that is what is
refused, with the value named in the message.

The model supplies the pattern through DateFormatRole for the same reason it
supplies the tag colours: it is the one object here holding config, and a
delegate reading config itself would be a second source of truth.

Backlog item 62.

1 files changed, 25 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 ff6efc4..844217e 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
@@ -118,7 +118,7 @@ taking that too literally.
 | 59 | Archive and Mark all read shipped with the same icon | presentation | XS | **done** |
 | 60 | Next thread dead-ends on the last reply of an expanded thread | defect | XS | **done**; already fixed by 5487d58, see below |
 | 61 | `test_mainwindow` fails intermittently, about 1 run in 20 | testing | S | open; predates the card list, reproduced on f72dba9 |
-| 62 | No config option for the date format on a card | presentation | XS | open |
+| 62 | No config option for the date format on a card | presentation | XS | **done** 2026-08-11 |
 | 63 | No way to see sent mail, and no filter for it | workflow | S | open |
 | 64 | The Sync button carries a mailbox icon, not a refresh one | presentation | XS | **done** 2026-08-11 |
 | 65 | No full code review and optimization pass | correctness | ? | open, unspecified |
@@ -4092,6 +4092,30 @@ and `CardDelegate` passes it down.
 
 **Size: XS.** One key, one parameter, one width calculation.
 
+### Outcome (done)
+
+Built as specced: `[general] date_format`, empty by default, passed down as a
+parameter rather than read inside `CardLayout`. Three things worth recording.
+
+- **The format reaches the LAYOUT, not only the painter.** It sits on
+  `CardLayout::Input`, because `compute()` reserves the date's width from
+  `widestDateSample()`. A pattern that reached only the `drawText` call would be
+  elided into a rect sized for the system format, which is the same clipping
+  the bold-font fault produced. The test asserts both halves and was confirmed
+  by mutation: making the width ignore the format fails it.
+- **`widestDateSample()`'s static cache had to go.** It memoised one sample, so
+  whichever format arrived first would have sized every later one. It is now a
+  plain call, at the cost of one `QLocale` lookup per row, which is what
+  formatting the date itself already costs.
+- **Validating a pattern is harder than it looks, and the first test fixture
+  was wrong.** `toString()` treats nearly every letter as a field, so `banana`
+  formats as `bpmnpmnpm` (`a` is AM/PM, `n` the minute) and `hello` as `22ello`.
+  Those are nonsense but they vary with the instant, so a "does this contain a
+  field" check cannot reject them and should not pretend to. What `Config`
+  rejects is the case that actually harms: a pattern whose output is CONSTANT,
+  found by formatting two different instants and comparing. `xyz` is such a
+  pattern and is what the test uses.
+
 ## 63. No way to see sent mail, and no filter for it
 
 **Observed (user, from the notes):** "Sent mail filter".