docs: "60fps setInterval" / "≤60 Hz broadcaster" stated as guarantees, but only the follower/backgrounded-broadcaster path documents degradation — main-side sync loop doesn't

[carochacs]

CLAUDE.md states:

startTimeSync — 60fps setInterval slaving panels to <audio>.currentTime

and separately:

Sent at ≤60 Hz by _startPopupBroadcaster … the same broadcaster throttles to ~1 Hz [when backgrounded]

setInterval is browser-clamped/deprioritized in a backgrounded tab — the doc explicitly acknowledges this for the popup broadcaster, with follower-side rAF extrapolation as the documented mitigation. But the main-window startTimeSync loop is the same setInterval mechanism and has the identical exposure (e.g. main window minimized/backgrounded while a popped-out follower window is focused) — and no fallback or even acknowledgment is documented for it. Every in-main-window panel synced by startTimeSync would degrade to ~1 Hz too, with no interpolation to smooth it over (that machinery only exists on the follower side).

Suggest either: drive startTimeSync off requestAnimationFrame or the <audio> timeupdate event instead of setInterval (removing the exposure), or explicitly document that a backgrounded main window degrades all in-window panel sync, not just followers.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}