-- §5.5 cross-resolution ranking, issue #113. The size term scores a release
-- against the band for its own resolution, so it says nothing about how
-- resolutions rank against each other: an at-target 1080p and an at-target
-- 4K both score `size_at_target`, and a 4K a couple of gibibytes over target
-- lost to a 1080p that was merely on target. `resolution_pref` being an
-- ordered list already implies a preference; this is the weight that makes
-- the scorer honour it.
--
-- The last entry of `resolution_pref` is worth nothing and each earlier one
-- `resolution_step` points more. 300 is chosen against the seeded 4K band
-- (target 22 GiB, 60 points per gibibyte over): five gibibytes of overshoot,
-- so a 4K up to 27 GiB beats an at-target 1080p and a bloated 4K past that
-- does not. Below target the same arithmetic asks a 4K to be within about
-- four gibibytes of its target to win, which keeps an 8 GiB 4K that looks
-- like mud from beating a good 1080p.
UPDATE policies
SET    score_weights = json_set(score_weights, '$.resolution_step', 300),
       updated_at    = strftime('%Y-%m-%dT%H:%M:%fZ', 'now');