Add offline detection with a generic "You're Offline" screen

[imbenjamin]

Summary

Adds app-wide offline/connectivity detection for Dionysus Player, primarily used against LAN-only Jellyfin servers.

• ConnectivityMonitor — a @MainActor @Observable singleton (isOffline), the single signal any part of the app can route to. The only writer is JellyfinAPIClient.sendRaw, the choke point every endpoint call funnels through: a transport-level failure (no response at all) reports offline; reaching any real HTTP response — success or an HTTP error status — reports back online.
• Checks happen at launch, resume, and every page load: AppState.start() routes a launch-time connectivity failure to a new .offline phase (distinct from .login); DionysusPlayerApp fires a lightweight GET /health probe on every foreground transition; every screen's own load already goes through sendRaw.
• A generic "You're Offline" screen (OfflineStateView) that Home, Search, Collection, and Asset Detail gate their "nothing to show yet" states on, with a Retry that reloads whatever the user was doing. Already-loaded/preloaded content is never blanked out by a stale/background offline flag.
• Profile/Settings stays reachable while offline — the pre-login .offline screen offers a "Go to Settings" button that opens ProfileView directly; post-login the tab bar is always present regardless of connectivity state.
• Mid-playback connectivity loss is also handled: a new PlaybackState.reconnecting case (bridged from AetherEngine's .stalled phase) drives a "Reconnecting…" indicator distinct from ordinary buffering, and a terminal .failed state now actually surfaces an error overlay (previously silent — the video just froze with no message). When that failure coincides with the app already being offline, the shared offline screen is shown instead, with a retry that resumes in place rather than restarting from zero.

Bugs found and fixed via live on-device testing

• App hanging indefinitely on the launch splash screen when offline, due to .shared's default 60s request timeout — fixed with a 20s per-request timeout.
• Tapping an item from an offline/cached Home screen produced a permanently part-loaded detail page that never showed the offline screen — AssetDetailView now checks offline state before its preloaded-item branch.
• Home's dynamic rails (genre/studio/actor/director) failed silently by design with no way to recover — added tracking + an auto-retry on reconnect.

Follow-up review (second commit)

Two internal performance fixes found reviewing the above, no behavior change:

• The 20s request timeout was enforced via a withThrowingTaskGroup racing against Task.sleep, spinning up an extra Task on every API call — replaced with a plain per-request URLRequest.timeoutInterval.
• ConnectivityMonitor.reportFailure()/reportSuccess() wrote isOffline unconditionally, which — since @Observable change-tracking fires on every assignment regardless of whether the value changes, and four screens read isOffline directly in body — was re-rendering whichever of those screens was on screen on every single network call app-wide, including the 10s playback-progress heartbeat during video playback. Guarded both to no-op when the value wouldn't change.

Testing

• Full unit test suite: 492 tests, 0 failures.
• Manual on-device verification (physical iPhone): offline-at-launch, offline mid-browse with retry, dynamic-rail auto-recovery, item-detail offline handling, and reconnect flows across Home/Search/Collections.
• Player mid-stream connectivity handling implemented per plan; automated Simulator driving doesn't work on the Player screen (documented limitation), so this leans on the same manual verification approach as other Player-screen changes.

🤖 Generated with Claude Code