`PlayerSession` is a god-object — three unrelated domains in one class

778 lines owning: now-playing/queue state, playback history, the saved-playlist library, a UI-facing loading message, and the persistence plumbing for all three. Each addition made sense in isolation — the loading-message infrastructure was explicitly built to be shared, and the history/library code arrived with #4's and #16's work — but the result carries three separate reasons to change: how playback state persists, how history retention works, how playlists import and export.

An MVVM-strict split would be three `@Observable` stores (`NowPlayingStore`, `HistoryStore`, `PlaylistLibraryStore`), each with its own `JSONDocumentStore`, composed by a thin facade or no facade at all. Whether it's worth doing now depends on whether History and the Library keep growing independently — the seams are already visible as the file's own MARK-comment sections, so splitting later means untangling call sites that currently just read `session.something`.

Review the open pull request #79 first, then inspect PlayerSession's MARK-comment sections and the call sites that read session.something. The issue describes possible store boundaries, but completion depends on deciding whether to split the stores now and how they should be composed.

Written by the indexing model from the issue text.