Pure: turn a guard-stashed path into the ordered route chain to replay. Home is always first (back-stack root); a /play path additionally inserts its Details screen between Home and the player (the details path is the play path minus the trailing "/play").

Build the /details route for a deep link. The :type is just a display hint (ItemDetails resolves the REAL type from the fetched item). The ?deeplink=query does double duty: it marks this as an untrusted deep-link entry (so ItemDetails validates the id, sending an invalid one back to Home per cert), AND it carries the intent — "open" lands on the springboard; "play"/"shuffle"/"trailer" auto-launch the matching action once the item resolves. The intent is the SENDER'S explicit choice (the route decides), never inferred from the resolved item. The "Playing

Look up a saved server entry by its Jellyfin server id (GUID). Returns the entry ({ name, id, baseUrl, originalUrl, ... }) or invalid. The pure match logic lives in config.bs (findServerInList) next to the saved_servers shape it matches.

Active routed views that ARE a media player (a deep link arriving over one must tear it down before launching the next, not stack on top).

A deep-link itemId is concatenated raw into the details route AND the metadata-fetch URL ("/Items/"), neither of which is URL-encoded. Reject an id carrying URL-structural characters (/ ? # & = | % or whitespace) so a crafted contentId can't reshape either — a whitelist of the characters real Jellyfin ids (GUIDs, hex +/- dashes) actually use. Deliberately NOT a strict GUID match: the goal is to block injection, not to assume an exact id format.

Safe-token check for deep-link fields that ride UNENCODED into the details route — mediaType in the PATH ("/details//...") and action in the QUERY ("?deeplink="). Both come from sender-controlled launch params. Blocks the URL-structural characters (/ ? # & = | % and whitespace) a crafted value would use to inject extra path/query segments, while still allowing clean-but-unknown values through — a future Jellyfin item type or a forward-compat action verb degrades gracefully downstream (ItemDetails resolves the real type; an unknown action is treated as "open"). Mirrors isPlausibleDeepLinkItemId's whitelist approach.

Toast shown when a deep link arrives but the user must authenticate first — it explains why nothing happened yet and that the content will open after sign-in. No-op if nothing stashed.

RUNTIME (app already signed in): resolve the stashed deep link's server and act.

• no/absent server, or it's the active one -> replay now.
• a different SAVED server -> prompt to switch.
• an unknown server -> can't connect; toast + discard. When NOT signed in (user at pre-login), do nothing: the stash rides until login and validates on whatever server they sign into.

Continuation of performServerSwitch once the off-thread reachability probe returns. On an unreachable target, surface the error and discard the deep link. On success, reuse the Change-Server machinery (resetRouter -> point at the new server -> SignOut -> reenterLogin); the stashed deep link survives the teardown and replays once the new server's login completes.

The server-switch prompt was answered (or dismissed). On "Switch", run the pre-flighted switch; on cancel, discard the stashed deep link.

IDENTITY, not a flag. Every dialog delivers its result on its OWN node, so holding the node we opened and comparing it against the event's is what tells us the event is ours — and it stays correct if a second main-thread flow ever observes result on the same port. The old path could not do this: every dialog wrote one shared SceneManager field, so it needed an isPendingServerSwitch flag to keep routed views' dialogs from cross-firing here.

It is also what makes a SECOND cast arriving mid-prompt correct with no code here, and the mechanism is worth stating because it rests on port delivery being ASYNCHRONOUS. Cast B overwrites the stash and calls promptServerSwitch again; presentOverlayDialog supersedes dialog A, which resolves as cancelled inside that call. But that result only reaches us at Main()'s next wait(0, m.port) — by which time promptServerSwitch has already reassigned m.serverSwitchDialog to dialog B. So A's event arrives and this guard rejects it: no toast, no stash wipe, and the prompt on screen is the one whose state the stash actually matches. Were delivery synchronous the guard would not save us: A's cancel would run while m.serverSwitchDialog still POINTED at A, so it would be accepted as the live dialog and wipe m.pendingSwitchServer and the stash — out from under the prompt B is about to show.

Parse a Roku deep-link contentId into { itemId, serverGuid, action }. contentId is the only deep-link field that survives BOTH Roku ingress paths intact (cold-start /launch standardizes only contentId+mediaType; /input forwards arbitrary params but /launch does not), and Roku forbids "&" inside it — so the whole contract rides inside contentId, pipe-delimited (Roku's own documented convention, e.g. series=x|Season=1). We mint it as "id=|serverId=|action=" (key names mirror Jellyfin web's ?id=&serverId=), and still accept a bare itemId (manual ECP tests, legacy). serverGuid is "" when absent (=> the active server). action defaults to "open" (land on the page, no autoplay) and is normalized to lower case; the consumer treats any UNKNOWN action as "open" too, so the contract is forward-compatible — a future verb degrades gracefully on an older build. Duplicate keys are LAST-WINS ("id=a|id=b" => "b") — an emergent property of the loop, pinned by a spec so a refactor can't silently change it. A value may itself contain "=" (we split each pair on the FIRST "=" only), so a key=value whose value carries an "=" is preserved, not dropped.

Perform the confirmed switch. Pre-flight the target FIRST (non-destructive) so an offline server never strands the user. The probe runs on a Task thread (ServerReachableTask) so the up-to-8s reachability check can't freeze remote input; the switch itself continues in onServerProbeDone once the verdict lands back on the main loop.

Ask before switching servers (it signs the user out of the current one).

This runs on the MAIN thread, which has no component scope for observeFieldScoped, so the result comes back through Main()'s message port instead of a scoped observer — see the two-channel contract at the top of source/utils/dialogs.bs. main.bs routes every result event on its port to onServerSwitchDialogResult below.

Read + clear whatever is stashed and replay it after a successful login (or immediately when already authed). Deep link wins over a guard path. Always navigates Home first so it is the back-stack root.

Runtime replay (app already signed in, deep link for the active server). Unlike the post-login path above, this does NOT prepend Home — an in-app cast shouldn't flash through the Home screen.

• already on the target item's LOADED details -> launch the action in place (no fetch, no re-mount); for "open" we're already showing it, so nothing to do. The itemContent guard matters: a lingering empty details would otherwise swallow the cast.
• otherwise -> hand the intent to JRScene.resolveDeepLink, which VALIDATES the id (a fetch) BEFORE navigating. An invalid id never disturbs the active session — it just toasts. A valid id then navigates (replacing an active player for a playback cast, else a plain push).

Stash a deep link (cold-start or runtime) as a structured intent for replayAfterLogin. Parses the contentId; records itemId + mediaType (+ serverGuid for the server resolver). Replaces the old queue-seed approach — ItemDetails now builds the queue from the validated item (real type + bookmark), so no queue work happens here. itemName is an OPTIONAL display title the sender (a casting client) may include so the server-switch prompt can name what's being cast — we can't fetch it ourselves before the switch (it lives on a server we're not yet authed to). Empty for bare/unknown senders.

COLD start: if the stashed deep link names a saved server, point the login at it BEFORE beginLogin runs (no prompt — there is no active session to disrupt). An unknown/absent GUID is left alone: login proceeds normally and the deep link validates on whatever server we land on (graceful error -> Home if the item isn't there).

True when a non-playback ("open") deep link would stack a details screen on TOP of an active media player, and so must be dropped rather than enacted. jellyfin-web's display-mirroring fires a DisplayContent ("open") on EVERY item-detail browse while JellyRock is the cast target, and the Roku OS can hand us an "open" deep link mid-playback — neither is an intent to interrupt playback, so the controller's browsing must never yank the cast target off the video. A PLAYBACK action (play/shuffle/trailer/instantmix) is exempt: it legitimately REPLACES the player (replacePlayer below). activeSubtype is the active routed view's subtype ("" / invalid when there's no active view). Pure so the rule is unit-testable without a live node.