handoff: withdraw the splash rate, and strike the section that carried it

Told the port plainly: their arithmetic was right, the 35-40 is withdrawn,
keep 60 for every screen, and do not average or split anything. Struck the
previous section's heading in place rather than deleting it.

Carried the instrument lesson across, because it is worth more than the
number: the guest timebase does not remove the pacing artefact, since the
game's animation clock is frame-coupled rather than being the guest
timebase. My control verified capability -- does this clock track real time
-- when the question was configuration: is the quantity I divide by coupled
to the frame rate.

Also told them what this leaves: both halves of the human's finding 4 that
were mine are answered and neither points at their export, so their own
unbound-A observation is now the strongest candidate and it is theirs.

docs/re/splash-declared-vs-captured.md

@@ -1,6 +1,9 @@
-# The declared timeline **does** reproduce the captured splash — and the unit rate is **per-GamePart**
+# The declared timeline **does** reproduce the captured splash
 
-**Status: ✅ two results, one of which corrects me.** 2026-09-01.
+**Status: ✅ §1 stands. ❌ §2 is WITHDRAWN** — see
+[`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The rate claim was the
+emulator's frame rate; the timeline result never divides by a duration and is
+unaffected. 2026-09-01.
 Instrument: ⟨disc⟩ for the declared side, ⟨capture⟩ for the observed side.
 **No renderer is anywhere in this comparison** — it is a keyframe table against a
 vertex stream.