fix(portals): re-check the movie after waiting, and follow the alternative

Three findings, two of them regressions from the previous round.

Awaiting a pending discovery before failover let the user navigate during
that wait: the continuation then ran against whatever controller was current
and could answer one film's playback failure by starting another film's
alternative. Both waits — failover and pinned Play — now re-check that the
same movie still owns the screen.

Pinned Play also needed the wait it did not have. Pressing Play while the
pin lookup was still out concluded "nothing is pinned" and started the
route's own source, making a persisted preference depend on worker latency.

And the position bridge still accepted only the route's ids, so an external
player running an alternative had every progress update discarded: the
resume point stayed where playback began and a switch an hour in rewound the
lot. The session matcher and the bridge now share one ownership predicate,
since a page that shows Stop for a session whose progress it throws away is
the bug in two halves.

The test for the external case previously set the position signal directly,
which bypassed the very filter that was broken; it now drives the bridge.

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

docs/architecture/vod-multi-source.md

@@ -263,9 +263,13 @@ serves both, because two would eventually disagree.
 ## Failover
 
 Only fires when `Settings.vodAutoFailover` is on, and it first awaits a
-discovery still in flight — a stream can fail faster than SQLite answers,
-and concluding "nowhere to go" against an empty controller would strand the
-user on the error screen with alternatives landing a moment later.
+discovery still in flight — a stream can fail faster than SQLite answers, and
+concluding "nowhere to go" against an empty controller would strand the user on
+the error screen with alternatives landing a moment later. `stillOwnsScreen()`
+does that wait and then re-checks the session, because the user can navigate
+during it and the controller afterwards may belong to a different film; the
+pinned-Play path takes the same wait, or a persisted pin would lose to worker
+latency.
 Ranking (`pickFailoverTarget`):
 
 1. never tried this session — a **hard filter**, not a preference
@@ -311,6 +315,12 @@ another click opened a second player. The page therefore claims a session that
 matches either the route's own stream or the alternative multi-source says is
 active (`VodDetailsPlaybackBindings.activeSource`).
 
+`ownsContent()` answers that question once, for both consumers: the session
+matcher AND the playback-position bridge. They cannot be allowed to disagree —
+a page that shows a Stop button for a session whose progress it discards keeps
+the resume point at wherever playback began, so a switch an hour later rewinds
+the whole session.
+
 Stop then has to win over the pin. The primary action consults the pin first —
 that is what makes "make this the main source" decide where playback starts —
 but when a session is already running the same button reads Stop, and doing