feat: own the message-pane zoom and persist it

Zoom was Chromium's, not the application's: the web view handled the
keys natively and never told anyone, so there was no value to save.
qtmaildir now owns it. Zoom in, out and reset are real actions, in the
View menu and rebindable through [keys], and the factor is persisted to
the UI state file. Ctrl+wheel over the body zooms and Ctrl+middle-click
resets, both filtered by ancestry from an application-level filter: the
events are delivered to an internal QQuickWidget the web view creates
lazily, so a filter on the view itself never sees them.

The factor is clamped to 0.5 - 3.0, and NaN, infinity, zero and negative
values fall back to 1.0, since a corrupt state file must not be able to
leave the pane unreadable with no visible way back.

Both risks the plan flagged turned out not to exist, verified by probe
rather than assumed. The application QAction wins over the web view's
native zoom key, so the tracked factor cannot diverge from what is on
screen. And the factor survives setHtml(), so the web view is the single
source of truth and needs no reapply per render.

A third finding is worth recording because it produced a wrong fix
first. A probe using QTest::keyClick() reported Ctrl++ as a dead
binding, and a test was written asserting that. Both were wrong: Ctrl++
is exactly what the '+' key emits on an Italian layout, confirmed
against the real keyboard, and it is the shipped default. Whether a
symbol needs Shift is a property of the layout, not of Qt, and
keyClick() reproduces neither. The test now only checks that every
default parses, and the comment in defaultBindings() says not to
re-derive this from synthetic input.

Ctrl+= is a second binding for reset, skipped when [keys] gives it to
something else.

Also fixes a pre-existing bug the new config key exposed. [general]
entries were read as "general/<key>", which matches nothing: QSettings'
INI backend treats a section literally named [general] as its own
fallback section and strips the prefix. notmuch_config had therefore
never worked. Both keys are now read without it; the file format is
unchanged.

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

1 files changed, 33 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 debf79a..2f8e0ce 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
@@ -37,7 +37,7 @@ taking that too literally.
 | 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 |
 | 3 | Too few clickable affordances, shortcuts are the only route | discoverability | M | **done** |
-| 4 | Message-pane font size does not survive restart | persistence | S | open |
+| 4 | Message-pane font size does not survive restart | persistence | S | **done** |
 | 5 | Thread list is cramped, poor readability | presentation | S | open |
 | 6 | Opened message stays unread | behavior | S | open |
 | 7 | HTML view should be default for HTML messages | behavior | XS | **verify first, may already be done** |
@@ -261,6 +261,38 @@ already exists.
 - Route the actions through item 3's `QAction` conversion so they appear in the
   View menu, which also makes the reset discoverable.
 
+### Outcome (done)
+
+Built as described, and both of the plan's stated risks turned out not to
+exist. Probed rather than assumed:
+
+- **The application `QAction` wins over Chromium's native zoom key.** The plan
+  called this "the one real risk in the item". It is not one: the action fires
+  and the web view's own handling never runs, so the tracked factor cannot
+  diverge from what is on screen.
+- **Zoom survives `setHtml()`.** The plan expected the view might reset it on
+  navigation and asked for a reapply per render. Not needed; the web view keeps
+  the factor, so it is the single source of truth and there is no second copy.
+- **Do not test key reachability with synthetic input.** A probe using
+  `QTest::keyClick()` reported `Ctrl++` as a dead binding, and a test was
+  written asserting it. Both were wrong: `Ctrl++` is exactly what the `+` key
+  emits on an Italian layout, confirmed against the real keyboard, and it is
+  the shipped default. Whether a symbol needs Shift is a property of the
+  layout, not of Qt, and `keyClick()` reproduces neither. The test now only
+  checks that every default parses.
+- `Ctrl+=` is a second binding for reset, skipped when `[keys]` gives `Ctrl+=`
+  to something else. Ctrl+wheel zooms and Ctrl+middle-click resets, both
+  filtered by ancestry from an application-level filter: the events land on an
+  internal `QQuickWidget` the web view creates lazily, so a filter installed on
+  the view itself never sees them.
+
+**A pre-existing bug surfaced while adding the config key.** `[general]`
+entries were read as `general/<key>`, which matches nothing: QSettings' INI
+backend treats a section literally named `[general]` as its own fallback
+section and strips the prefix. `notmuch_config` had therefore never worked.
+Both keys are now read without the prefix; the file format the user writes is
+unchanged. Regression test in `test_config`.
+
 ## 5. Thread list is cramped
 
 **Observed:** rows are tightly packed, everything is uniform, the UI reads as