Merge #208: size bands scale with episode runtime

Closes #208

DESIGN.md

@@ -307,6 +307,26 @@ measured by its full size. That is the behaviour today, and it makes a pack look
 oversized rather than undersized — it fails toward rejecting a good pack rather
 than grabbing a bad one, and the next search after a refresh has the real count.
 
+**A band describes a rate, not a fixed size per episode.** The shipped values
+are read against a **reference runtime of 45 minutes**: a 1080p target of 2 GiB
+means 2 GiB per 45 minutes of episode. Before the per-episode figure is compared
+against them, a band's floor and target are both scaled by
+`runtime / 45`, where `runtime` is the series' minutes-per-episode from TMDB
+metadata. For a typical drama around 45 minutes the shipped numbers keep exactly
+their current meaning; a 22-minute show is judged against roughly half the floor
+and half the target instead of being rejected for weighing half of what an hour
+of video weighs. The shipped band values themselves do not change — the
+reference runtime is chosen so they do not have to.
+
+**A missing or zero runtime is the reference runtime.** When metadata carries no
+per-episode runtime, or carries zero, the scale factor is 1 and the band applies
+unscaled — exactly today's behaviour. The rule does not guess a duration, for
+the same reason the unknown episode count does not guess a number.
+
+**Movies are not scaled.** This applies to episodes only. A movie's bands are
+already tuned against feature length, so its floor and target keep their current
+meaning regardless of the movie's own runtime.
+
 Source tier (`Remux > BluRay > WEB-DL > WEBRip > HDTV`) survives as a small
 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