perf(subtitles): publish the overlay cue array once per drain tick

[superuser404notfound]

Fixes the three items in #271, all inside the overlay drain tick.

One publication per tick, not one per packet

$subtitleCues was published once per decoded packet. applyEventMutations
takes the channel's array inout and @Published exposes get/set with no
_modify, so every event both copy-on-wrote the array and republished it. Each
publication carries the whole cumulative store, and a snapshot does not say
which elements are new, so every consumer walked all of it: O(n) per packet,
O(n²) per drain window. @edde746 measured 104 publications and 608,608 cue
visits per second on a typeset ASS track, add=0, 43 ms/s of host time spent
on walks that found nothing.

The tick binds the channel's array once, applies the whole batch to it, and
writes it back once, only if the batch changed something. An event that decodes
but resolves to a cue the store already holds, or a trim matching no open
window, no longer costs a publication. Retention pruning moves out of the
per-event path to once per batch, and the retained-store insert finds same-start
cues over the equal-start run by binary search instead of scanning the whole
array (both the dedupe and image-replace keys require an exact startTime
match, and the store is start-sorted).

The batch is bounded, on a PTS boundary

The drain window is bounded in seconds of content (backscan + lead) and never in
packets, so its size was set by the file's subtitle density while the loop ran
synchronously on the main actor with no suspension point.

The bound has to fall on a PTS boundary, as #271 points out: the cursor is a
bare PTS advanced by lastDecodedPts.nextUp, so a cut inside a same-PTS run
would skip its remainder instead of resuming it, and dense ASS deliberately
keeps hundreds of distinct payloads on one timestamp. batchEnd extends the cap
forward to the end of the run it lands in; a single run longer than the cap
decodes whole. The OCR worker's existing prefix() cap gets the same
correction, since a container that splits a display set across packets shares a
PTS there too.

A capped batch also defers reconstruction finalization, whose contract is "after
the whole window decoded": the successor composition may sit in the remainder.

A slow tick is not a seek

drainPlan compared the live playhead against the playhead captured at the
previous tick's start, so any tick longer than the 2.5 s jump threshold made
the next one reset onto a fresh, disjoint window: a positive feedback loop,
since the reset window is the expensive one. Forward drift is now forgiven up to
the elapsed wall time. Backward drift is not, because playback never moves the
playhead backwards, and re-reading sourceTime at tick end (the other option in
the report) would swallow a seek that landed mid-tick, whose only detector this
is.

Verification

• 1380 tests in 208 suites pass, 15 of them new (Issue271DrainPublicationTests).
• swift build -Xswiftc -strict-concurrency=complete clean.
• tvOS Simulator build clean.

Device verification of the publication rate on the reporter's ASS sample is still open.

Reported and measured by @edde746.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HX5zV3Fcf7Nzq4DYGdXvQE