fix(dashboard): keep the hero skeleton until every hero source has loaded

The hero dropped its skeleton as soon as the history load resolved empty
and came back moments later with an Xtream recently-added slide (that
query waits for the favorites), moving every rail below by 316 px twice.
On J1 this read renderer.layoutShiftScoreSettled 0.235 on every macOS
iteration and was a race on the Linux runner.

The hero now stays in its skeleton while it has no slide and any of its
sources (history, favorites, Xtream recently added) is on its first load.
DashboardDataService no longer settles xtreamRecentlyAddedLoading before
the playlist inventory has loaded, where "no Xtream playlists" was
decided on a still empty inventory.

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

docs/architecture/iptvnator-ui-guidelines.md

@@ -568,8 +568,9 @@ launch with sources). Rail skeletons are gated per rail
 
 The top block (the dashboard hero) keeps its immediate skeleton: it reserves
 the space above everything else, where a late insertion would push the whole
-page down. Use the same rules for any page that stacks independently loading
-blocks.
+page down. For the same reason it stays until every source that can fill it
+has loaded, not only the first one. Use the same rules for any page that
+stacks independently loading blocks.
 
 ### Reload with content on screen: non-destructive indicator
 

docs/architecture/performance-journeys.md

@@ -176,8 +176,7 @@ stable in the other two). Every iteration shows the same two shifts of 0.118:
 about 12 ms after the first card the `dashboard-recent-sources-rail`, which
 holds the first card, moves up by 316 px, and 12-65 ms later it moves back
 down. Something 316 px tall above it is removed and inserted again during
-startup, a flicker #1738 did not cover. The counter is working as intended;
-the flicker is a separate fix.
+startup, a flicker #1738 did not cover.
 
 On the Linux CI runner (`Performance journeys` job of #1756, run
 36618062068) the same flicker is a race: the measured iterations read
@@ -185,6 +184,17 @@ On the Linux CI runner (`Performance journeys` job of #1756, run
 after the first card), and the one hit shows the same two 316 px moves of
 the recent-sources rail.
 
+The 316 px element was the dashboard hero. The J1 profile has no history
+and no favorites; its only slide is an Xtream recently-added title, and that
+query waits for the favorites. The hero dropped its skeleton as soon as the
+history resolved empty and came back with that slide moments later. It now
+keeps the skeleton until every source that can feature a title has loaded
+(`DashboardHeroSlidesPresenter.loading`), and
+`DashboardDataService.xtreamRecentlyAddedLoading` no longer settles before
+the playlist inventory has loaded. After the fix (macOS, 2026-09-30): both
+counters were 0 in all 12 iterations of two runs, every window closed on
+`quiet` and `lateShifts` was empty.
+
 #### Main-process counters
 
 With `IPTVNATOR_PERF_CAPTURE=1`, which the journey sets,
@@ -658,10 +668,10 @@ in all eighteen runner iterations; the `spawnToFirstCardMs` P50 ranged from
 1,401 to 1,674 ms. All four stay evidence for now. Runner counters also
 differ from a Mac (12 and 571 there, the fast path without the Linux-only
 `getWindowState` call), so take J1 baseline values from the runner only.
-`renderer.layoutShiftScoreSettled` has no baseline either: the runner reads
-it as `stable: false` because the dashboard flicker it reports is a race
-there (see [Settle window](#settle-window)). Add the runner's number once
-that flicker is fixed and the counter is deterministic.
+`renderer.layoutShiftScoreSettled` has no baseline either: the runner read
+it as `stable: false` because the dashboard hero flicker it reported was a
+race there (see [Settle window](#settle-window)). That flicker is fixed; add
+the runner's number once runner runs read it as `stable` too.
 
 ### Weekly tightening
 

docs/architecture/workspace-dashboard.md

@@ -75,7 +75,10 @@ Render rules:
    full-bleed. All rails and the hero are skipped.
 3. The hero (`lib-dashboard-hero`) renders when it has at least one slide;
    see [Cinematic Hero](#cinematic-hero). It shows its own skeleton while
-   the first history load runs. An item enters recent history only after
+   it has no slide and any of its sources (history, favorites, Xtream
+   recently added) is still on its first load; dropping it earlier removed
+   the hero and inserted it again when a later source featured a title,
+   moving every rail below twice. An item enters recent history only after
    its stream has really played (see "Recently Viewed Confirmation" in
    `embedded-inline-playback.md`), so a channel that failed at once never
    becomes a hero slide.