fix(portals): let the height veto a width match, and hold the failure state

Two follow-ups to the previous round, both in code it introduced.

A width that matched exactly one sub-HD format ignored the height entirely,
so 640x480 came back as 360p — a measurement the numbers contradict. The
height now vetoes, but only in the direction that can be wrong: cropping
removes lines, so a SHORTER frame is a letterboxed master of that format and
the width still names it, while a taller one is a different shape and gets
no tag. That keeps the reason width is preferred in the first place.

And picking a source off the error screen cleared the failure state before
the switch resolved, so an alternative that could not be resolved left the
diagnostic on screen while the caption went back to claiming playback. The
flag now clears only once a switch actually starts something.

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

docs/architecture/vod-multi-source.md

@@ -65,7 +65,10 @@ Three rules follow, and each is enforced in code rather than by convention:
    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 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.
 
 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.