flaky: just test ts --full exits on the release clock's first rate estimates (~1 in 5 local runs) #5564

just test ts --full fails intermittently: within its first 30 s the export exits with

Error: the source's clock runs +32045.3 ppm off ours, past the 30 ppm the output's may follow

On main (3abf0161c, macOS arm64, debug as CI builds) 2 of 10 runs fail this way, and 2 of 5 on 323fda277. On CI, run 38659235632 failed the "TS full multiplex at its own rate" step with the same error (+21347.9 ppm): 1 of the 51 ts.yml runs between 2026-10-14 19:57Z and 2026-10-15 03:55Z.

In every failing run the first TS export release clock line is already far out, and the runs that pass log none, so they never leave the 30 ppm tolerance. On 3abf0161c:

run 4: drift_ppm -155315.5, -67119.8, -35380.8, -1418.6, -1418.6, +1251.8, +5241.8 (x3), +9750.4 (x3), exits 22 s after the first
run 6: drift_ppm -159776.5, +32045.3 (x2), exits

On 323fda277 the failing runs' first estimates read -286011 and -437557 ppm. The same source stays within 30 ppm in the runs that pass, so these are not a drifting source: they are estimates from the envelope's first few 2 s floors, against a 600 s window, and the exit's lost is read from the same envelope, so an envelope fitted to a handful of start-up floors can end the export before it has a window's worth of them. I have not diagnosed which floors skew it.

Repro (about 75 s a run):

for i in $(seq 10); do just test ts --full >/tmp/full-$i.log 2>&1; echo "$i rc=$?"; done

Noticed while testing #5553, whose --full fails the same way locally (3 of 6); the failures above are on main without it.

(Written by Claude Opus 5.5)