perf(dashboard): hold rail skeletons back so empty rails stop shifting the page (#1738)

* perf(dashboard): hold rail skeletons back so empty rails stop shifting the page

On every launch with sources the dashboard shifted by about 0.23 (the
"good" CLS threshold is 0.1). The rails render as soon as their own data
arrives, and each loading rail showed a 328 px skeleton immediately. On a
normal profile the live-favorites and recent-content sources resolve empty
15-20 ms later, so their skeletons flashed and collapsed and every rail
below jumped up by about 360 px. J1 never saw it: its layout-shift window
ends at the first card, which is painted just before the collapse.

Rail skeletons now wait out a 300 ms grace period (createRailSkeletonGrace)
and appear only for a rail still loading after it; the hero keeps its
immediate skeleton because it reserves the top of the page. Recorded over
three renderer reloads of a seeded profile, the dashboard's layout shift
drops from 0.219-0.234 to 0.0004, with the real rails painted at the same
time as before. Plan thread C5, journey J1.

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

* fix(dashboard): gate rail skeletons per rail, never above visible rails

Addresses the Codex and Greptile reviews on #1738. The component-wide grace
timer started when the dashboard was created, so a rail that begins loading
later (Xtream recently added, TMDB) showed its skeleton at once and could
still flash and collapse; and after the grace period a slow rail's skeleton
could appear above rails that already showed cards, pushing them down and,
if it resolved empty, back up.

createRailSkeletonGates now keeps one gate per rail, in template order: the
grace period counts from that rail's own loading start, a skeleton is never
inserted above a rail that already has cards (the real rail inserts at most
once instead), and a shown skeleton stays until its own rail finishes so the
first arriving rail does not collapse the others in a cascade. Nine specs
cover the fast path, per-rail start, the no-content-below rule, latching,
reloading, destroy and a zero grace period. The seeded-profile timeline is
unchanged at 0.0004 across three renderer reloads.

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

---------

Co-authored-by: 4gray <fourgray@proton.me>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/iptvnator-ui-guidelines.md

@@ -543,6 +543,30 @@ mirrors the row/card geometry it precedes (see Channel List Item and Cover
 Grids). The unified Favorites/Recent page gates this on `isLoading`, set only
 while its item list is empty.
 
+### Pages of independently loading blocks: delayed skeletons
+
+The dashboard renders each rail as soon as its own data arrives, and several
+rails resolve empty on a normal profile. A per-rail skeleton shown
+immediately therefore flashed for a few tens of milliseconds and collapsed,
+pulling every rail below it upwards (a layout shift of about 0.23 on each
+launch with sources). Rail skeletons are gated per rail
+(`createRailSkeletonGates` in
+`libs/workspace/dashboard/feature/src/lib/rails/dashboard-skeleton-grace.ts`):
+
+- a skeleton waits out a grace period (`DASHBOARD_RAIL_SKELETON_GRACE_MS`,
+  300 ms) counted from when *that* rail started loading, since Xtream and
+  TMDB rails start after the local ones;
+- it never appears above a rail that already shows cards: the placeholder
+  would push visible content down, and back up if the rail resolves empty,
+  while the real rail inserts at most once;
+- once shown, it stays until its own rail finishes, so skeletons do not
+  vanish in a cascade when the first real rail arrives.
+
+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.
+
 ### Reload with content on screen: non-destructive indicator
 
 A reload of a list that is already rendered (the collection page's