spec(playlist): unverified behavior when an account's playlists overflow the Save-to popup's scroll area (no implementation)

[Kotmin]

Context

Spun out of #16 (playlist picker feature) per K's direction — a "what if"
question flagged as a possible future bug, not something to act on now.

What's untested

docs/probes/save-to-playlist-dom-findings.md documents the native "Save to
playlist" popup: all of a captured account's 18 playlists (16 user-created +
Watch later + Shorts) rendered directly into the DOM inside a single
yt-list-view-model with a fixed max-height: 220px (presumably
scrollable). No continuation tokens or lazy-load markers were found anywhere
near it — confirmed no pagination for that account size.

Never tested: what happens for an account with enough playlists to
actually overflow that 220px area. Two real possibilities:

1. It's a plain scrollable overflow — all playlists are already in the DOM
   (same as the 18-playlist case), and scrolling just reveals them. In this
   case our playlist-picker feature (spec(playlist): keyboard-driven fuzzy playlist picker for current video (no implementation) #16) already works correctly with zero
   extra code, since our scraper already collects whatever's in the DOM.
2. YouTube caps or virtualizes the list past some count/height — meaning an
   account with many playlists could have some silently missing from what
   our scraper collects, so the fuzzy picker (spec(playlist): keyboard-driven fuzzy playlist picker for current video (no implementation) #16) would never be able to
   find/target them.

No account available during #16's research had enough playlists to trigger
this, so it's unconfirmed either way.

Why this is its own issue, not blocking #16

Doesn't block shipping #16 — most accounts won't have enough playlists to
hit this. Filed separately so it doesn't sit as a permanent asterisk on #16's
scope, and so a future report of "the playlist picker doesn't see playlist X"
on a playlist-heavy account has somewhere to land instead of looking like a
regression.

What would resolve this

A DOM capture (same method as #16's probes: open the "Save to playlist"
popup on an account with enough playlists to overflow 220px, save the page,
trim to the <yt-sheet-view-model> fragment, redact real playlist names)
showing whether more yt-list-item-view-model rows exist in the DOM than fit
in the visible area, or whether the list is genuinely capped short of the
account's real playlist count.

---

No PR against any item here without K's explicit sign-off, same convention as
#6/#12/#16.