[spawvn]

Closes #1096

Problem

On iPad, switching the sidebar back to Home leaves the dashboard rows on stale cached content until pull-to-refresh. It's most visible after reading a book opened from another page. Cause: SwiftUI adds, removes (about 1 ms later), and re-adds the dashboard while keeping its state. Each row's view .task is cancelled mid-request, and its load-once flag (pinned rows: isLoading guard) then blocks the retry. Full trace in #1096.

Approach

Rows load through view models they own, following the same direction as #1069's OfflineView browse models:

• DashboardSectionViewModel owns the row's pagination and its load task. The view's .task is gone: onAppear calls ensureLoaded(), which starts a first-page load only when none has completed or is running. A load in flight survives the view being removed and re-added.
• Newest request wins. reload() cancels a load in flight and restarts from the first page instead of being dropped by an isLoading guard, and it returns once the newest load settles, so manual refreshes still acknowledge after content lands. Superseded loads end quietly (loadID check, no error alert). Loaded items stay on screen until the new first page replaces them, as before.
• DashboardPinnedSectionViewModel does the same for pinned collections and read lists. They keep their current behavior of refreshing (local items, then sync) on every appear, but join a refresh that's already running for the same server, and a reload command restarts it.
• DashboardRefreshCoordinator's register/acknowledge flow is unchanged.
• AGENTS.md documents the rule: rows load through view models, never in a view .task, with no load-once flags or isLoading guards that drop a re-run.

Why this shape, not another

• Robust rows rather than preventing the re-add: the add/remove/re-add comes from swapping the detail NavigationStack's root under NavigationSplitView, and views get removed and re-added in other cases too, like tab switches mid-load on iPhone. Loading shouldn't depend on a view task surviving.
• No memory in the coordinator for reloads posted while the dashboard isn't mounted: a dashboard created when Home is selected loads current data anyway.
• Row-owned models, not models owned by DashboardView: each row already reloads through the coordinator's commands, so nothing needs to reach the models from above. Moving them up (and replacing the acknowledgement tracking with direct awaits) is possible later without changing the rows' behavior.
• DashboardSectionDetailView is untouched: it's pushed onto the stack rather than swapped in as the root, so this trigger doesn't reach it.

Validation

• make build passes on iOS, macOS, and tvOS.
• iPad A16 simulator against a local Komga, with temporary appear/disappear/task logging:
  • Before: Read Lists → read list → read a book → close → Home. onAppear → onDisappear 1 ms later → onAppear 19 ms later. Every row's request, plus the pinned read list/collection syncs, failed with Request cancelled. Keep Reading stayed without the book just read.
  • After: same steps. All row requests return 200, the pinned syncs complete (Synced readlists, Synced collections), and Keep Reading lists the book just read first, with no pull-to-refresh.
• Pull-to-refresh still waits for every row before dismissing.
• Closing a reader opened from the dashboard itself reloads the rows. The close refresh and the deferred flush arrived 70 ms apart, and the newer load won.

Manual test plan

1. iPad: Read Lists → open a read list → read a few pages of a book → close → tap Home → Keep Reading shows that book without pull-to-refresh.
2. Same with Series/Books as the starting page.
3. Pull-to-refresh on the dashboard → the spinner stays until the rows have reloaded.
4. Open a book from Keep Reading, finish it, close → Keep Reading and Recently Read update in place.
5. iPhone: switch tabs while the dashboard is still loading → returning to Home shows loaded rows.

Note

#1095 also touches DashboardSectionView; I'll rebase whichever of the two lands second.

🤖 Generated with Claude Code