Guard strict Soulseek album wishlist downloads

[Maitresinh]

Summary

• keep explicit album/discography wishlist rows in the album cycle even when Spotify metadata says single or ep
• when album_downloads.atomic_publish is enabled, skip album-cycle residual tracks instead of submitting them as orphan per-track downloads
• in strict Soulseek album mode, fail fallback/partial album-bundle outcomes instead of falling through to the per-track flow

Why

This preserves the “publish only complete albums” guarantee for Soulseek wishlist album downloads. Without these guards, an album wishlist item can still leak into the classic per-track flow via classification, residual grouping, or album-bundle fallback, which can publish partial albums or isolated tracks.

Tests

• python -m pytest tests\\wishlist\\test_classification.py tests\\wishlist\\test_automation.py tests\\test_album_bundle_dispatch.py -q
• python -m ruff check core\\wishlist\\classification.py core\\wishlist\\processing.py core\\downloads\\album_bundle_dispatch.py tests\\wishlist\\test_classification.py tests\\wishlist\\test_automation.py tests\\test_album_bundle_dispatch.py

[Maitresinh]

Follow-up from live validation on my NAS: I tightened the strict Soulseek album guard so it compares completed files against the requested album track count, not only the selected Soulseek folder's own file count.

This catches the case where Soulseek returns a folder that is internally complete, e.g. 3/3 files, but the wishlist album expects 10 tracks. In strict atomic album mode that now fails the album batch instead of falling through to per-track staging/downloads.

Validation added:

• test_dispatch_soulseek_atomic_uses_requested_album_track_count
• targeted run: 124 passed
• targeted ruff: all checks passed

[Maitresinh]

Follow-up from another live NAS validation pass: I found one more re-download loop that is separate from atomic album publishing.

Repro observed locally:

• an album had previously completed and been moved into the Plex library
• the user deleted that album from Plex/the library
• some of the same album tracks remained in the wishlist
• the next wishlist album cycle expanded those leftover tracks back into an album download, so the deleted album reappeared

I pushed a small follow-up commit to this draft PR:

• detect wishlist tracks whose completed track_downloads.file_path entries now all point to missing files
• remove those tracks from the wishlist before manual/automatic processing builds batches
• store a permanent deleted_from_library ignore reason so automation does not re-add the track after the normal ignore TTL
• when an album id is available, add an album blocklist row so future album cycles cannot rehydrate the deleted album

Validation:

• uvx --with-requirements requirements.txt --with-requirements requirements-dev.txt python -m pytest tests/wishlist/test_cleanup.py tests/wishlist/test_wishlist_ignore.py -> 19 passed
• uvx --with ruff python -m ruff check core/wishlist/processing.py core/wishlist/ignore.py tests/wishlist/test_cleanup.py tests/wishlist/test_wishlist_ignore.py -> passed

[Maitresinh]

Follow-up from the live NAS/Plex setup after testing the latest main/3.0.1 behavior.

I pushed the exact deployed workaround branch here for traceability:
https://github.com/Maitresinh/SoulSync/tree/agent/nas-deployed-wishlist-guards-20260714

Commit:
aed8f967 Track deployed NAS wishlist album guards

What was still happening on the live setup:

• the auto-wishlist was running and finding tracks, but only a few album batches are selected per run;
• albums that had already failed atomic Soulseek completion kept occupying those album slots on the next run;
• another failure path still removed terminal/incomplete atomic wishlist albums from wishlist_tracks, so they could disappear instead of being retried later;
• when a Soulseek source produced 11/12 tracks, atomic publish correctly blocked Plex publication, but the wishlist row handling still needed to become “defer/cooldown”, not “remove”.

What the deployed branch adds on top of the previous strict-album guard work:

• marks atomic Soulseek album failures with soulseek_atomic_unavailable:*;
• defers those albums to the back of the wishlist instead of deleting them;
• skips repeated atomic-unavailable album groups for a configurable cooldown window, so they do not monopolize future wishlist runs;
• keeps album wishlist runs album-only in this deployment;
• validates requested expected track count before publishing;
• publishes to the Plex music folder only after the selected Soulseek album source completed.

Live validation on the user NAS:

• Hotline by 80s Stallone failed at 11/12; it was not published to Plex, and after the fix was restored/deferred in the wishlist with cooldown.
• The next run skipped cooled-down failures and moved on to other albums.
• Engaged downloaded and published complete: 9 FLAC files.
• Beach downloaded and published only after 4/4 files completed.
• Electric Nights downloaded and published only after the selected source completed.
• Plex then found Beach and Electric Nights as albums for 80s Stallone.

This branch is intentionally a trace of the deployed NAS patch rather than a polished minimal PR. If useful, the smallest upstreamable follow-up is probably the atomic-unavailable deferral/cooldown behavior plus replacing the remaining remove-on-terminal-failure path with defer-on-terminal-failure.