feat: option to list playlist folders at the top

[Ritze03]

Summary

Adds a behavior.group_folders_first toggle (Settings → "Playlist Folders First") that lists your Spotify playlist folders at the top of the Playlists tab, above playlists, keeping each group's existing order. Off by default. Handy because folders keep their creation date and otherwise sink to the bottom of the recency-sorted list.

Implementation

The reorder lives in get_playlist_display_items() — the single source of truth for the visible list — as a stable sort_by_key that hoists Folder items. get_playlist_display_count() and get_playlist_display_item_at() delegate to it, so rendering and index-based selection (keyboard + mouse) can't desync. No-op where there are no folders (slim/Web-API builds, non-Spotify sources), so nothing changes when the toggle is off.

Testing

• New unit test: folders hoist stably only when enabled; selection index resolves against the reordered list.
• cargo fmt --all, cargo clippy --no-default-features --features telemetry -- -D warnings, cargo test --no-default-features --features telemetry — all green (327 tests).

[LargeModGames]

Nice feature, and routing count/selection through get_playlist_display_items() is the right call. One thing to fix before merge though:

reconcile_playlist_selection bypasses the new folders-first sort. In src/infra/network/library.rs, both index lookups (~L1299 and ~L1332) compute the restored selection by enumerating playlist_folder_items.iter().filter(is_visible) — same filter, but without the group_folders_first sort that get_playlist_display_items() now applies. The resulting index is stored in selected_playlist_index, which rendering and get_playlist_display_item_at then resolve against the sorted list.

So with the toggle ON, after a library refresh: root [P0, folderA, P1, folderB], preferred = P1 → reconcile computes index 2 (P1's spot in unsorted order), but the displayed order is [A, B, P0, P1], so index 2 is now P0. The highlight lands on the wrong playlist whenever a folder precedes the selected playlist in root order.

Fix is small: derive these two indices from the sorted get_playlist_display_items() (or apply the same folder hoist) instead of re-filtering playlist_folder_items directly, so this path shares the single source of truth like the rest.

Everything else (config plumbing, stable sort key, settings wiring, unit test) looks correct.

[LargeModGames]

Re-reviewed after 7bad466. The reconcile_playlist_selection bypass is fixed exactly as intended: both index lookups (the direct-visible path at L1344 and the folder-descent path at L1376) now enumerate get_playlist_display_items() instead of re-filtering playlist_folder_items directly, so the stored selected_playlist_index is computed against the same sorted list that rendering and get_playlist_display_item_at resolve against. get_playlist_display_items() is now the sole place the visibility filter is applied.

The added regression test (reconcile_restores_selection_against_folders_first_order) nails the exact [P0, folderA, P1, folderB] failure case from the last review: with the toggle on, restoring selection to P1 now yields display index 3 and resolves back to the Playlist { index: 1 }, not P0.

Verified locally on the branch:

• cargo clippy --no-default-features --features telemetry -- -D warnings — clean
• cargo test --no-default-features --features telemetry — 328 passed, 0 failed

LGTM. Thanks for the quick turnaround.