docs: close the GUI layout review, release 0.16.0

Stage 9 of the GUI layout plan: the roadmap item the review was raised
under is closed, so the plan and the findings document go with it — what
they established now lives in STANDARDS and the CHANGELOG.

STANDARDS gains the rule the review produced: a size that must follow the
theme is measured at build time, not written as a pixel constant, because
a hand-tuned number is only correct for the theme it was tuned against.
rowOverlap, captionColumnWidth, textColumnWidth, activityRowsHeight and
initialSplitOffset are the worked examples.

The CHANGELOG entry keeps to what the user can see: the window opens at
the size it asks for and drags smaller, the Jobs divider is draggable,
History columns hold their content on a scaled UI, and the Settings
button row and block spacing are as their layouts intended.

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

docs/STANDARDS.md

@@ -12,6 +12,16 @@ what a whole-project review looks at, in [REVIEW.md](REVIEW.md).
 - Fixes with severity ≥ medium → regression test.
 - Documented intentional behavior → section below, not a backlog bug.
 - UI view constructors accept `*app.Service`; call `app.Open()` only from `run.go`.
+- A size that must follow the theme is **measured at build time, not written as
+  a pixel constant.** `theme.Padding()` and text metrics depend on the running
+  app's theme, text size, and DPI, so a hand-tuned number is only correct for
+  the one theme it was tuned against and clips under any other. Measure the real
+  widget, or derive the value from the theme, in a named helper: `rowOverlap`
+  (theme padding), `captionColumnWidth` and `textColumnWidth` (the widest of the
+  actual strings), `activityRowsHeight` (the list's own row template). The same
+  applies to a ratio computed from an absolute width — see `initialSplitOffset`.
+  A raw pixel literal is left only where nothing about it tracks the theme, and
+  says so in a comment.
 
 ## Config file compatibility