re: finish the --help audit -- a stale percentage and a missing noun, both shipped

The METHOD entry I wrote an hour ago says to read your tool's own --help as if a
stranger wrote it. I had done that for ONE of sixteen leaf commands, which is the
"a rule written down is not a rule applied" failure this corpus already records
twice. Finished it across the whole surface.

One survivor, and it fails in two ways at once. `screen render --settle` said a
narrow window means the bundle never settles, "(42 % of them, mostly loop*
fragments)".

MISSING NOUN: inside `screen render`, "them" reads as the builds you would render.
The 42 % is over composable bundles -- a different and much larger set including
~1 700 two-element fragments a user of that flag never renders. ui-settle-time.md
states its population precisely; the help inherited the number without it.

STALE: recomputed under the corrected reader, the composable figure is 862/2211 =
39 %, not 731/1758 = 42 %. The POPULATION GREW BY 453, which is the keyframe
record-layout fix's signature -- it times a group's final pose, so bundles that
previously showed one timed keyframe now show two and qualify. Third consequence
of that fix not being swept, after fade_quads.py and screen-transitions.md's
0.87-4.08 s fade-in.

And the share a --settle user actually faces is 38 %: 185 of 491 screen builds.

Corrected in the help text with all three numbers and their populations, and in
ui-settle-time.md, whose three-row table is marked pre-fix and superseded rather
than edited in place. Verified by artifact -- the tool's --help output is quoted,
not merely recompiled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/settle-narrow-rate.txt

@@ -0,0 +1,20 @@
+# Narrow settle windows: what share, and OF WHAT. 2026-08-30.
+# instrument: crates/sylpheed-formats/examples/settle_narrow_rate.rs
+# Found by auditing sylpheed-cli's own --help against what the corpus
+# establishes -- the audit METHOD gained an hour earlier, applied to the
+# remaining 15 leaf commands rather than the one that prompted it.
+
+population                                        n     narrow (<10 u)   share
+SCREEN BUILDS (is_build, what `screen render` renders by default)
+                                                491         185      38 %
+COMPOSABLE bundles (is_composable, what --all admits)
+                                               2211         862      39 %
+
+ui-settle-time.md quotes 731 / 1758 = 42 % over composable bundles.
+--- END ---
+
+# The pre-fix figure was 731/1758 = 42 %. The population grew by 453 because
+# the keyframe record-layout fix times a group's FINAL pose, so bundles that
+# previously showed one timed keyframe now show two and qualify.
+# 🔴 Third consequence of that fix not being swept, after fade_quads.py and
+# screen-transitions.md's 0.87-4.08 s fade-in.

docs/re/structures/ui-settle-time.md

@@ -127,7 +127,25 @@ Of the **1 758** composable bundles carrying two or more keyframe times:
 | settle window < 10 units | 731 | 42 % |
 | mean window | 49 units | — |
 
-The 42 % are mostly `loop*` animation fragments, which are **meant** to be in
+🔴 **These three rows are PRE-FIX and are superseded (2026-08-30).** They were
+computed before the keyframe record-layout fix, which times a group's **final**
+pose — so bundles that previously showed one timed keyframe now show two and enter
+the population. Recomputed under the corrected reader
+([`data/settle-narrow-rate.txt`](../data/settle-narrow-rate.txt)):
+
+| population, ≥2 keyframe times | n | narrow (<10 u) | share |
+|---|---|---|---|
+| **screen builds** (`is_build` — what `screen render` renders) | 491 | 185 | **38 %** |
+| composable bundles (`is_composable` — what `--all` admits) | **2 211** | 862 | **39 %** |
+| *the pre-fix figures above* | *1 758* | *731* | *42 %* |
+
+⚠️ The **population grew by 453**, which is the fix's signature and the reason the
+share moved. And the share a user of `--settle` actually faces is **38 %**, over
+screen builds — not 42 % over a wider set that includes ~1 700 fragments they will
+never render. The tool's own help said "42 % of them" without saying of *what*;
+corrected there too.
+
+The narrow ones are mostly `loop*` animation fragments, which are **meant** to be in
 motion and have no settled pose to find. **Check the window width before trusting
 the midpoint.** A narrow window is the data saying "this bundle never settles",
 not a settle time with a small error bar.