Playlist init: Make library optional + Define Library Attachment Strategy

[semohr]

Playlist constructors currently require a library parameter:

    def __init__(
        self,
        library: AnyLibrary,  # <-- Required, even when not needed
        name: str,
        description: str | None = None,
        tracks: list[AnyTrack] | None = None,
    ):

This feels awkward because we're forced to provide a library even when just creating playlists locally, there is no guarantee the library is actually connected or valid at that point, and the base class doesn't enforce a consistent signature (no abstract __init__). Overall this introduces an implicit dependency on a live service too early imo.

Proposal:

In migration or transformation scenarios, we often construct playlists, transform or filter them, and only then decide to persist them. Requiring a library upfront forces us to bind to a service prematurely, which doesn't match this workflow. Instead, we could allow constructing playlists without a library and attach it later when needed.

def __init__(
    self,
    name: str,
    description: str | None = None,
    tracks: list[AnyTrack] | None = None,
):

The library would then be attached explicitly via playlist.attach_library(lib) or playlist.library = lib. This allows creating playlists locally and attaching them retroactively once a concrete backend is available. This should make it easier to create multi-user and multi-library workflows. Also makes working with the library more intuitive imo.

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!