feat(core): rank resolutions in the score

`resolution_pref` only gated eligibility, so every release was scored
against its own resolution's size band and a 23 GB 4K lost to an
at-target 1080p. Each step up the list is now worth `resolution_step`
points, seeded at 300: five gibibytes of 4K overshoot, so a 4K up to
27 GB wins and a bloated one still does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DESIGN.md

@@ -261,6 +261,25 @@ tiebreaker. Seeders are log-scaled and small: enough to complete, past that it
 does not matter. Telesync, CAM and screener are **hard filters**, not low
 scores.
 
+**How resolutions rank against each other.** Size is scored against the band
+for the release's own resolution, so on its own it says nothing across
+resolutions: an at-target 4K and an at-target 1080p both score the top of the
+size term, and a 4K a couple of gigabytes over target loses to a 1080p that is
+merely on target. That is wrong — `resolution_pref` is an ordered list, and the
+order is a preference, not just an eligibility filter.
+
+So each step up `resolution_pref` is worth a fixed number of points. The last
+entry is worth nothing and every earlier one a step more. A resolution the list
+does not carry scores nothing rather than being penalised, the same as an
+unclaimed resolution: no ranking is no opinion.
+
+The step is sized against the size term, not chosen in isolation. With the
+seeded 4K band — target 22 GB, 60 points per gigabyte over — a step of 300 is
+five gigabytes of overshoot: a 4K up to about 27 GB beats an at-target 1080p,
+and a bloated 40 GB 4K does not. Below target the same arithmetic asks a 4K to
+be within about four gigabytes of its target to win, which is what keeps an 8 GB
+4K that looks like mud from beating a good 1080p.
+
 Exact numbers are policy rows, tuned by hand. The model is the decision.
 
 ### 5.6 Two phases of truth