fix(portals): let the height veto a width-derived quality, and refresh route facts

Both of these are gaps I saw and chose not to close last round; a
reviewer was right that neither survives its own reasoning.

The shape check only ran below 1200, so the HD ranges kept publishing
wrong-but-confident labels: 1440x1080 is anamorphic 1080 and 1600x900 is
900p, and both were "720p" with `api` provenance — the provenance that
means the provider said so. Ranges are fine up there, the standard widths
really are far apart, but only once a known height can veto the answer.
Same rule the matched formats already used: a shorter frame is a
letterboxed master, a taller one is a different shape and gets no tag.

And the route row picked up provider facts only when discovery reran. On
a sparse panel `get_vod_info` can answer with no year and no TMDB id, so
the movie key is unchanged, nothing reruns, and the row keeps stating
nothing — leaving `audioDiffersFactually` one-sided and the dub warning
unreachable on exactly the switch it exists for. It now takes those facts
on without rediscovering, merged onto the existing row so a probe result
already sitting there survives.

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

docs/architecture/vod-multi-source.md

@@ -61,14 +61,20 @@ Three rules follow, and each is enforced in code rather than by convention:
    letterboxed masters are cropped vertically — a 2.39:1 1080p film is 1920×800,
    and 800 alone is indistinguishable from a 1280×800 encode. With no width, a
    height is trusted only within 5% of a standard frame height; otherwise no tag
-   is emitted. Below the HD widths the ranges stop working: 800×600
-   and 800×450 are neither 480p nor each other, and 720 wide is NTSC 480p or
-   PAL 576p depending only on the height. Those formats are therefore matched
-   rather than bucketed, and an unrecognised shape returns nothing rather than
-   a label that would be published as an `api` fact. A known height still has
-   to be consistent with the match: cropping only ever *removes* lines, so a
-   shorter frame is a letterboxed master of that format, while a taller one
-   (640×480 against 640×360) is a different shape and gets no tag.
+   is emitted. Below the HD widths the ranges stop working: 960×540 and 1024×576
+   are two formats inside one 900–1199 range, 800×600 and 800×450 are neither
+   480p nor each other, and 720 wide is NTSC 480p or PAL 576p depending only on
+   the height. Those formats are therefore matched rather than bucketed, and an
+   unrecognised shape returns nothing rather than a label that would be
+   published as an `api` fact.
+
+   A known height has to be consistent with the width **on every tier**,
+   ranges included. Cropping only ever *removes* lines, so a shorter frame is a
+   letterboxed master of that format, while a taller one is a different shape:
+   640×480 against 640×360 below, and 1440×1080 (anamorphic 1080) or 1600×900
+   against the 720p range above. All of those get no tag. Bucketing HD widths is
+   otherwise sound — the standard widths really are far apart — but only once
+   the height is allowed to veto the answer.
 
 Provenance is per-field and changes over time: at discovery a row has only
 `parsed` tags, because the `content` table stores no container, codec or audio.