fix: preserve heroItem during loadHomeData reloads to prevent Continue Watching hero override

[EierKopZA]

Description

Fixes a bug where the home screen hero item would be incorrectly overridden by a Continue Watching item during catalog-triggered data reloads.

Root cause: When loadHomeData refreshes categories (e.g. after Trakt sync or pull-to-refresh), chooseInitialHero(categories) unconditionally selects the first item from the first non-empty row — which is the "Continue Watching" row when it exists. This overwrites whatever item the user was currently focused on. The hero-update LaunchedEffect in HomeScreen.kt attempts to correct this via focus-based hero updates, but during a reload the categories are rebuilt with fresh data instances, causing the key-based guard to bail out early (item at the focused position now has a different instance key). Result: the hero gets permanently stuck on the first CW item until the user navigates to a new row.

Fix (2 parts):

1. Preserve hero during reload — HomeViewModel.loadHomeData(): If a heroItem already exists in the UI state, preserve it across the reload by attempting to find its match (by id + mediaType) in the fresh categories. Falls back to keeping the old hero instance if not found, with the LaunchedEffect correcting it on next focus change.

2. Guard the hero fallback — HomeScreen.displayHeroItem: The ?: displayCategories.firstOrNull()?.items?.firstOrNull() fallback was silently showing the first row's first item when the hero was null, even after categories were populated. Gated to only apply during the initial-load window when uiState.categories is empty, preventing silent hero corruption mid-session.

Changes

File	Change
HomeViewModel.kt	Preserve current heroItem during loadHomeData reloads by matching id/mediaType in fresh categories
HomeScreen.kt	Gate null-coalescing hero fallback to initial-load window only

Cleanup

Temporary HeroDebug diagnostic logs were removed before merge.

Testing

• ✅ Navigate to a non-CW row, trigger a catalog reload — hero no longer jumps to CW item
• ✅ Initial load (no pre-existing hero) still picks the correct initial hero via chooseInitialHero
• ✅ Hero-update LaunchedEffect continues to correct hero on focus change post-reload
• ✅ Fast scrolling hero update delay still functions correctly
• ✅ :app:compileSideloadDebugKotlin passed
• ✅ :app:compilePlayDebugKotlin passed

[Copilot]

Pull request overview

Fixes a home-screen UX bug where catalog-triggered reloads could overwrite the currently focused hero with the first “Continue Watching” item by preserving the existing heroItem across loadHomeData() refreshes and tightening the hero null-fallback behavior in HomeScreen.

Changes:

• Preserve an existing uiState.heroItem during loadHomeData() by matching it (id + mediaType) against freshly loaded categories, falling back to the prior instance if not found.
• Gate HomeScreen’s “first row / first item” hero fallback so it only applies during the initial-load window (when uiState.categories is still empty).
• Adds extensive HeroDebug logging for diagnostics (currently present in the PR).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
app/src/main/kotlin/com/arflix/tv/ui/screens/home/HomeViewModel.kt	Preserves current hero across reloads by remapping it into refreshed categories; adds HeroDebug logging.
app/src/main/kotlin/com/arflix/tv/ui/screens/home/HomeScreen.kt	Prevents mid-session hero corruption by limiting the null-fallback; adds HeroDebug logging in hero/focus watcher.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[EierKopZA]

@copilot apply changes based on this feedback

[EierKopZA]

@copilot apply changes based on the comments in this thread

[EierKopZA]

@ProdigyV21 - should work as expected.