SABnzbd compat: priority numeric mapping is off-by-one (sab_priority_to_priority)

[thedancingdeveloper]

Summary

sab_priority_to_priority in crates/nzb-web/src/sabnzbd_compat.rs (used by addfile, addurl, and priority-change requests) maps client-supplied numeric priority strings to the wrong internal Priority value.

Current (wrong) mapping

fn sab_priority_to_priority(s: &str) -> Priority {
    match s.trim() {
        "-100" | "3" => Priority::Force,
        "2" => Priority::High,
        "1" => Priority::Normal,
        "0" => Priority::Low,
        _ => Priority::Normal,
    }
}

Real SABnzbd mapping

Verified against sabnzbd/sabnzbd @ 5.1.x, sabnzbd/constants.py:120-127:

REPAIR_PRIORITY = 3
FORCE_PRIORITY = 2
HIGH_PRIORITY = 1
NORMAL_PRIORITY = 0
LOW_PRIORITY = -1
DEFAULT_PRIORITY = -100   # displayed as "Normal"
PAUSED_PRIORITY = -2

So the correct mapping is -1→Low, 0→Normal, 1→High, 2→Force, -100→Normal. Our own sab_priority_matches function (used for queue filtering, ~80 lines earlier in the same file) already uses these correct values — it directly contradicts sab_priority_to_priority, which is proof this is a bug and not an intentional convention.

Impact

Any client (Sonarr, Radarr, NZB360, ...) that sets a job's priority via addfile/addurl/priority-change gets the wrong priority applied. E.g. client-requested "High" (1) becomes "Normal"; "Force" (2) becomes "High"; "Low" (-1) isn't matched at all and silently becomes "Normal"; "3" (real SAB's "Repair" priority) is misread as "Force".

Fix

Align sab_priority_to_priority with sab_priority_matches's numeric table.