fix: cap playlist helpers at one per visit instead of one per batch

[KrX3D]

Your hypothesis was right. Standing down our own cascade settled it:

autoload_skipped x3     our cascade did stand down
keep-one.register x3    the same three helpers appeared anyway

YouTube's viewport refill drives the refetches, not schedulePlaylistAutoLoad. Filtering leaves one tile on a screen that fits 4–5 rows, so the list is starved and YouTube pulls the whole playlist unaided in 780ms:

18:44:00.675  batch collect starts
18:44:00.693  helper 1 (initial response)
18:44:01.022  continuation -> helper 2
18:44:01.239  continuation -> helper 3
18:44:01.455  continuation
18:44:03.338  collector's FIRST extra batch — 2.6s late, race already over

The fix that follows: a helper exists only so the list is never empty (an empty list is what makes YouTube TV reload the page). It doesn't have to be a new one per batch — and the measurement shows the extras buy nothing, since YouTube keeps loading regardless. Each extra is stranded permanently in the virtual list's data model (unreachable on Tizen 5.0, 654577e), i.e. a blank navigable slot for the rest of the visit.

So later all-watched batches now return [] and reuse the existing helper. Four become one, and that one is retired and DOM-removed by the existing path when the final !hasContinuation batch lands.

Guarded twice, since getting it wrong means an empty list and a page reload: reuse is tied to the location hash the helper was created under, and a page-level playlist response resets the cap (which also clears the stale retired ids behind the page-restart deadlock 654577e described).

Separately noted: the 2.5s pacing delay is now dead weight — zero fetch failures this run, and it's what puts the collector 2.6s behind a 780ms race. Left for its own change.