diff --git a/docs/re/ui-keyframe-time-unit.md b/docs/re/ui-keyframe-time-unit.md
index 1cf83a92..0c8237df 100644
--- a/docs/re/ui-keyframe-time-unit.md
+++ b/docs/re/ui-keyframe-time-unit.md
@@ -427,3 +427,42 @@ the five screens' correlations stand ([acceptance](five-screens-acceptance.md)).
 screen family, not a disc-wide field check, and our own decoder still defaults to
 the other reading behind `SYLPHEED_KF_TIME_SHIFT=1` — ⚠️ **a gate since removed;
 there is no way to select the old reading today, and nothing to set.**
+
+## ⚠️ 2026-08-30 — "the game presents at 27.6 fps" is not separated from "my container runs the guest slow"
+
+`sylpheed-port` warned that their boot timings carry a host deficit — 146.6 s of
+wall clock for 137.44 s of media, **+6.7 %**, because 720p Theora decodes below
+real time on a box with no GPU — and that any comparison between their seconds and
+mine must go through **media length, not wall clock**. Checking whether that
+reaches this page: **it does, and to the page's own headline.**
+
+Every rate here is a frame count over a wall-clock window on one container:
+
+| | window | rate |
+|---|---|---|
+| idle title, trials 1–3 | 10.40 / — / 10.60 s | 28.8 / 28.3 fps |
+| boot splash | 10.87 s | 27.6 fps |
+
+🔴 **A guest running at ~92 % of real time produces exactly these numbers**, and so
+does a game genuinely presenting at 27.6 fps. The two hypotheses are
+**indistinguishable by any measurement on this page**, and the three trials do not
+separate them — they share the container, so they are three samples of one
+confound, not three independent confirmations. This is the same shape as the
+plate-pulse phase lock: agreement across runs that measures the instrument.
+
+The same applies to the **8.5 %** splash-dwell excess in
+[`boot-order-and-splash-dwell.md`](boot-order-and-splash-dwell.md) — `1.085` and
+`1/0.92` are the same number arriving from the two readings.
+
+✅ **The port is not exposed.** It authors **declared units** — 240 and 195 — and
+reads seconds from nothing here. That row is still `decoded`, and its evidence is
+the disc, not the clock.
+
+❌ **What will not settle it, and I checked:** the `BGM_103` loop figures. Both the
+`9.44 s` start and the `61.87 s` cycle are wall-clock derived — that page states it
+outright, *"two derivations, neither converting bits to seconds"* — so they carry
+the same container pacing and cannot audit it.
+
+**What would settle it** is a media-length reference: play an asset whose duration
+is fixed by its own data — a movie, or a wave with a declared byte rate — and
+compare its wall clock against its media length in *this* container. Not run.