docs: record items 55 and 58, with their causes corrected

Both backlog entries stated a cause that measurement contradicted, and
both would have misled the next reader into fixing the wrong thing.

Item 55 blamed the thread view's size hint, computed as the sum of its
fixed column widths, and placed the fault on first run. The hint is
256px, not 886: a QTableView does not put its column sum in its size
hint, so that mechanism never applied. The trigger is the restore, in a
window narrower than the one the position was saved in.

Item 58 claimed the zoom range is unenforced and the first render
unusable. MessageView::clampZoom() has always enforced exactly the
README's 0.5 and 3.0; only the report was missing.

1 files changed, 16 insertions, 0 deletions

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1fdf212..fdbb08f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,22 @@ point at which they are stable.
 
 ## [Unreleased]
 
+### Fixed
+
+- **The message pane no longer comes back as a sliver.** A splitter position is
+  saved in pixels, so one saved in a wide window did not fit a narrower one: the
+  thread list kept its full saved width and the message pane got whatever was
+  left, in one real case 29px. The pane now has a minimum width and cannot be
+  collapsed, which covers the restore and the equivalent drag.
+
+### Changed
+
+- **An out-of-range `message_zoom` now says so.** The documented 0.5 to 3.0
+  range was already enforced on the way to the web view, so a `message_zoom` of
+  500 rendered at 3.0 rather than unusably, but nothing reported that the value
+  in the file was not the value on screen. It is now listed with the other
+  configuration problems at startup.
+
 ## [0.12.1] - 2026-08-09
 
 A single fix for a defect 0.12.0 introduced.