/memory: prev/next navigation on fact and episode detail screens

[dcellison]

Summary

When the operator drills into a fact or episode from the list view (or from search results), navigating to the next or previous row requires going back -> tap next number, which is a multi-step interaction. Add < prev and next > buttons directly on the fact-detail and episode-detail screens so the operator can walk through adjacent rows at the detail level the same way pagination walks through pages at the list level.

Scope

1. Fact-view detail. Add < prev and next > buttons on the fact-detail keyboard alongside the existing back and forget controls. The buttons walk through the source list at the row level.

2. Episode-view detail. Same buttons, same behavior. The fact-view code path is shared with episode-detail (single _build_fact_view), so this is one implementation covering both.

3. Source list awareness. The cache must remember which list seeded the detail view (facts list vs episode list vs search results) and the current row's position within that list. Tapping next > re-fetches the source list, advances the index, and opens the next row's detail view (or no-ops at the end).

4. Boundary behavior. Open design questions:

   • At the first row of the first page, hide < prev (parallel to how the list view hides < prev on page 0)? Or show it disabled?
   • At the last row of the last page, similarly: hide next > or disable?
   • Cross-page: tapping next > on row 4 of page 0 should advance to row 0 of page 1. Tapping < prev on row 0 of page 1 should go to row 4 of page 0. The operator should not need to bounce back to the list to cross page boundaries.

5. Search results. Same treatment if the source was a search; prev/next walks the search hits in score order.

Out of scope

• Display refinements to the dashboard, stats, or detail rendering (separate issue).
• A "wrap around" mode that cycles from the last row to the first.
• Any change to the underlying enumeration or sort order.

Risk

• Cache state grows: the cache currently stores memory_ids for the list view and is overwritten when the operator opens a fact. The new design must preserve the source list's memory_ids alongside the current detail's id, plus the current index. Care needed so the existing forget-fact flow still finds the right row to delete.
• Boundary-crossing requires re-fetching the source list because the cache window is one page; advancing past the page boundary needs the next page's rows.
• The 64-byte callback ceiling: prev/next buttons need to encode enough state to resume. Likely just an integer index, with the source list re-derived from cache.

Acceptance

• Fact-view detail shows < prev, back, next >, forget (or whatever the agreed final layout is) when the fact was opened from a list or search.
• Episode-view detail shows the same.
• Tapping next > on a row inside a page advances to the next row's detail without intermediate screens.
• Tapping next > on the last row of a page advances to the first row of the next page.
• Tapping next > on the last row of the last page is a no-op (or the button is hidden).
• Symmetric behavior for < prev.
• Forget still works correctly on the row currently in view (no off-by-one across the prev/next walk).
• Tests cover the cross-page boundary, the first/last boundary, and the forget-after-walk case.

Related

• Surface episodes in /memory dashboard #410 / feat(memory): add facts browser to /memory dashboard (#420) #421 (the list-view pagination this parallels at the row level).
• /memory: add recency-ordered Facts (N) browser #420 (preceding display polish).

[dcellison]

Triage by Kai

Triage summary: Well-scoped UX enhancement to add prev/next row navigation on fact and episode detail screens, allowing operators to walk through adjacent records without bouncing back to the list view. Moderate complexity due to cache state changes needed to track source list and current index alongside cross-page boundary navigation.

Priority: medium
Labels applied: enhancement
Related issues: #410, #420, #421, #422