Start the next Next Up episode before finishing the previous one's bookkeeping (issue #82)

[mapitman]

Summary

• PlaybackService.onPlaybackStateChanged(STATE_ENDED) ran a chain of sequential, awaited DB/DataStore work (clear enclosure position, mark read, read the auto-delete setting, possibly delete a downloaded file, clear lastPlayingItem) before playNextQueued() even started resolving and preparing the next episode. None of that bookkeeping is a prerequisite for starting the next episode's playback -- it was pure added silence on top of whatever buffering player.prepare() itself needs.
• Reordered so playNextQueued() runs first; the finished episode's bookkeeping now happens after, no longer blocking the transition.
• playNextQueued() used to rely on the caller unconditionally clearing lastPlayingItem to null right before it ran; since that line moved, playNextQueued() now owns clearing it on every early-return path itself (queue empty, item/feed missing, resolve failure), so behavior there is unchanged.

Testing (emulator, manual)

Verified end-to-end on the emulator with a real feed (This Week in Tech) and two queued episodes, using dumpsys media_session polling to get wall-clock timestamps around the transition:

• Streamed episode: old episode stopped, and the next episode's metadata/buffering state appeared ~1 second later (previously this alone would have waited on every DB write above). Audible playback then took a further ~14s to actually start -- that remainder is ExoPlayer's own network buffering for a fresh connection, not app-level delay, and matches the user's own hypothesis that streaming is the dominant remaining factor.
• Downloaded episode: metadata swap was effectively immediate (no intermediate "stopped" state observed at 1s polling resolution). The buffering phase before audible playback still took ~9.7s in this run, though, which is closer to the streamed case than expected for local file playback -- likely inflated by the emulator's virtualized disk/CPU rather than representative of a real device. Flagging this rather than overclaiming: a real-device comparison would give a cleaner read on how much of the original "substantial silence gap" this fully resolves versus how much is inherent ExoPlayer/decoder startup time.

This is a real, verified improvement to the specific inefficiency it targets (unnecessary sequential bookkeeping ahead of playback start), not a claim that it fully eliminates the gap for streamed episodes -- fully closing that would need pre-buffering the next episode while the current one is still playing (a bigger, separate architectural change).

Test plan

• ./gradlew assembleDebug testDebugUnitTest lintDebug
• Manual emulator verification (see above) with both a streamed and a downloaded Next Up transition

Refs #82