port: the clock freezes at settle -- my window is the game's, and the boot is known too fast

The Decoder measured build 4's top-level clock stopping inside [160,236]. The
exporter computes title's settle window as [160,236,198] from the file alone.
Same interval, two independent methods -- the first evidence for the settle
instant that does not come from our own renderer. ptcopyright reaching alpha
255 exactly at t=160 agrees from a third direction.

Corrects a claim in three places: timing.json, flow.json and boot.gd all said a
screen's dwell IS its keyframe group and the port reproduced 'the disc's own
pacing'. Build 4 declares ~120 presented frames and dwelled ~1100. The decision
to hold zero extra stands; the claim that it was faithful does not.

Checks their two declared spans against the file: both exact, with a 106-vs-105
interval-convention quibble that changes nothing.

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

port/scripts/boot.gd

@@ -350,8 +350,21 @@ func _process(delta: float) -> void:
 		return
 
 	# A screen holds at `rest` until it has arrived, then plays itself out and
-	# the next one begins. Nothing waits on a timer the disc does not carry: the
-	# pacing is each group's own timeline (authored/flow.json, `dwell`).
+	# the next one begins. Nothing waits on a timer the disc does not carry.
+	#
+	# 🔴 That is a choice made for lack of a number, NOT a reproduction of the
+	# game's pacing, and this comment used to claim otherwise. Measured in the
+	# draw stream (docs/port/DECISIONS.md, "The clock freezes at settle"): the
+	# top-level clock advances through the build-in, STOPS inside the settle
+	# window and holds -- build 4 declares ~120 presented frames and dwelled
+	# ~1100. The exit ramp is not on a timer; it plays when something makes the
+	# screen leave. Leaving AT settle, as the line below does, is leaving at the
+	# instant the real game starts waiting.
+	#
+	# The structure here is right and the duration is wrong: `_advance` is
+	# already caused by the next screen rather than scheduled, which is what the
+	# measurement says the game does. What is missing is the hold, and it goes
+	# in `authored/flow.json` `dwell` the day a capture times one.
 	if view.holding and view.time_units >= view.settle_time():
 		# The LAST screen in the sequence keeps holding. A screen plays itself
 		# out because something is taking its place; nothing is taking the