handoff: one units-per-second cannot be right, the splash timeline is confirmed, and H5 refuted

Three sections, the correction first.

The rate is per-GamePart: title ~57, splash ~35-40. I gave them 56.8 an hour
ago and said the reach was the title; the splashes now have their own number
with T read off the disc. The hold is what makes it safe to hand over -- 160
declared units in 4.514 guest seconds, with no T, no alpha slope and no
interpolation in the arithmetic, agreeing with the same screen's ramp which
shares none of its algebra. Told them a splash played at 60 runs 1.5-1.7x
too fast, which is a TIMELINE cause for the complaint we had both filed
under blur. Classified measured, not decoded, and told them not to extend
either number to any other screen.

The R1-re-opened 'declared timeline reproduces the captured splash' settles
in favour of the timeline: 39/50 exact under truncation, worst error one
alpha level in 255, nothing off by more than one. So their export's splash
keyframes are right and the rate was the defect.

Refutation attempt on their H5, recorded whether it survived or not: it does
not. build_12 and build_15 have identical declaration bodies, so identical
statistics is one fact rather than two coincidences -- as do 0/1, 2/3 and
11/14, while 4/7, 5/8, 6/9 and 10/13 genuinely differ. Also recorded the trap
I hit first: the dump header carries the build number, so the compared text
contained the label distinguishing the subjects and every pair read as
different. A self-comparison control caught it.

docs/re/data/title-pair-bundles-identical.txt

@@ -0,0 +1,35 @@
+# Refutation attempt on the Port's H5: 'build_12 and build_15 give BYTE-IDENTICAL
+# verify-screen statistics, and identical statistics point at one shared element,
+# not two coincidences.'  (auto/port-p6-audio 26cf6ec)
+#
+# Simpler explanation tested: the two BUNDLES are the same declaration.
+# Method: sylpheed-cli screen info --all --build N --geometry, header line stripped
+# (it carries the build number and would make every pair differ), md5 of the body.
+
+## control -- a build against ITSELF must come out identical
+   12 vs 12 : IDENTICAL -- control PASSES
+
+## pairs
+   entries 0   vs 1   : IDENTICAL declaration body
+   entries 2   vs 3   : IDENTICAL declaration body
+   entries 4   vs 7   : differ
+   entries 5   vs 8   : differ
+   entries 6   vs 9   : differ
+   entries 10  vs 13  : differ
+   entries 11  vs 14  : IDENTICAL declaration body
+   entries 12  vs 15  : IDENTICAL declaration body
+
+## verdict
+   REFUTED. Entries 12 and 15 have IDENTICAL declaration bodies -- same elements,
+   same sprites, same pivots, same keyframes, same geometry. Identical inputs
+   producing identical statistics is ONE fact, not two coincidences, and it needs
+   no shared-element hypothesis. Same for 0/1, 2/3 and 11/14.
+   Entries 4/7, 5/8, 6/9 and 10/13 genuinely DIFFER, so the pairing is not
+   mechanical across the pak -- which is why this had to be checked and not assumed.
+
+## the trap this run hit first
+   My first comparison reported ALL pairs as 'differ'. The dump's first line is
+   'build [N] ...', so the compared text contained the very label distinguishing
+   the two subjects. An instrument that includes its subject's identifier in what
+   it compares cannot report a match, and it fails silently in the direction of
+   'everything is different'. The self-comparison control is what caught it.