Pre-buffer the next Next Up episode while the current one is still playing

[mapitman]

Follow-up to issue #82 (PR #86). That fix removed the unnecessary sequential DB/DataStore bookkeeping that used to run before the next episode even started resolving/preparing, cutting the metadata-swap delay down to about 1 second. But it doesn't touch the remaining gap: ExoPlayer's own buffering time for the newly-loaded episode, confirmed via emulator testing at roughly 14s for a streamed episode (opening a fresh connection) and, more surprisingly, ~9.7s even for a downloaded one in that same test run (likely inflated by emulator disk/CPU overhead rather than representative of a real device -- worth re-measuring on hardware).

To fully close the "substantial silence gap" from issue #82, the next Next Up episode would need to start buffering before the current one finishes, so it's already ready (or much closer to ready) by the time playback actually needs to switch over -- the standard "gapless"/pre-buffering pattern.

This is a bigger, separate architectural change from #82's fix:

• PlaybackService currently only ever has one MediaItem loaded on the player at a time -- Next Up is deliberately managed externally rather than through ExoPlayer's own playlist/timeline (see the class comments referencing issue Fix Downloads screen duplicates and orphaned files (issues #176, #178) #179), so this can't just be "add the next item to ExoPlayer's playlist and let it preload automatically" without more thought about how that interacts with Next Up being externally mutable (reorderable, items added/removed) at any time.
• Media3 has PreloadMediaSource/DefaultPreloadManager for exactly this kind of use case, which would be the natural building block, but integrating it here needs design work: when to start the preload (e.g. some threshold before the current episode's end), how to handle Next Up changing while a preload is in flight, and how it interacts with the existing per-feed speed/volume-boost/start-position resolution in PlaybackMediaItemFactory.

Needs a design pass before implementation, not just a quick fix.

[mapitman]

Fixed in #91, merged. PlaybackService now routes ExoPlayer through Media3's DefaultPreloadManager and keeps whatever's at the head of Next Up warming up (connection opened, first chunk buffered) continuously, reacting to every queue mutation. At the STATE_ENDED transition, the pre-warmed MediaSource is handed to the player instead of a cold MediaItem when one's available and current, falling back cleanly to the old cold-start path otherwise. No cellular gating -- preloading follows the same policy as regular streaming.

Automated checks (build, unit tests, lint) all pass. The actual silence-gap reduction and the queue-mutation-during-preload fallback path still want a manual pass on device/emulator against the ~14s baseline measured for #82 -- flagging that as the one residual caveat since PlaybackService has no automated coverage.