fix(search): sort wanted list ascending so backlog isn't starved

[lolimmlost]

Summary

Fixes #376.

search_missing (and search_unmet_cutoff) could permanently re-search the same top MAX_CONCURRENT_SEARCHES items while items that had never been searched were never reached — logging a normal success line every cycle, so it looked healthy.

Root cause

src/utils/wanted_manager.py::_get_arr_records sent sortKey but no sortDirection:

params = {"page": "1", "pageSize": total_records_count, "sortKey": sort_key}

For lastSearchTime the *arr API defaults to descending, so the list comes back most-recently-searched first and never-searched items (lastSearchTime: null) last. search_handler.py::_filter_wanted_items then slices from the top (items[:max_concurrent_searches]), so it re-selects the items it just searched. With min_days_between_searches=0 the recent-search guard (_filter_recent_searches) never evicts anything either, turning this into total starvation of the backlog.

Confirmed against a live Sonarr in the issue thread: same endpoint and sortKey, only sortDirection varies — ascending yields the never-searched-first order the code intends.

Fix

Request the direction explicitly:

params = {
    "page": "1",
    "pageSize": total_records_count,
    "sortKey": sort_key,
    "sortDirection": "ascending",
}

Least-/never-searched items lead, which is what the job intends, and it is correct at any min_days_between_searches including 0.

Tests

Adds tests/utils/test_wanted_manager.py: a regression test asserting sortDirection=ascending in the request params, plus the empty-records early-return path. Full suite passes locally (pytest).

Credit to the original reporter for the diagnosis and live-Sonarr verification in #376.

🤖 Generated with Claude Code