feat(mobile): add channel scroll navigation

[tellaho]

Category: improvement
User Impact: Mobile readers can jump directly to their oldest unread message and return to the latest message with compact directional controls.
Problem: Opening an active channel at its newest message makes it easy to miss where unread conversation began, while moving back through history lacks a lightweight route to the live edge.
Solution: Capture the channel's unread boundary when it opens, offer an accessible up-chevron beneath the app bar to reach that stable target, then reveal the inverse down-chevron at the bottom whenever the reader is away from latest. Deep links retain precedence, and live-follow, pagination, composer resizing, and explicit scroll ownership continue to use the existing timeline behavior.

File changes

mobile/lib/features/channels/channel_detail_page.dart
Captures the channel's read state at open time and passes a stable unread snapshot into the timeline before the normal deferred read update advances it.

mobile/lib/features/channels/channel_detail_page/message_list.dart
Adds mutually exclusive oldest-unread and latest navigation, with accessible icon controls positioned at opposite edges of the message surface while preserving existing follow and deep-link behavior.

mobile/test/features/channels/channel_detail_page_test.dart
Covers the unread target, compact inverse controls, accessible tooltips, and placement beneath the frosted app bar.

Reproduction steps

1. Open a Flutter mobile channel that has unread messages without entering through a message or thread deep link.
2. Confirm an up-chevron appears directly below the channel app bar while the timeline remains at latest.
3. Tap the up-chevron and confirm the timeline scrolls to the oldest message that was unread when the channel opened.
4. Confirm the unread control is replaced by a down-chevron at the bottom of the timeline.
5. Tap the down-chevron and confirm the timeline returns to latest and resumes following new messages.

Screenshots

At latest — up-chevron to oldest unread	Away from latest — down-chevron to latest

Real iPhone 17 Pro Simulator captures from the neutral buzz-mobile-scroll-to channel.

Originating Buzz thread: buzz://message?channel=5b16c478-22d8-4ddd-951a-6036e19b81ff&id=6a78af32d7ac6f531b182c4e70dd5a04c503a2dab2ce2c0c74b2c6baa5921741&thread=6a78af32d7ac6f531b182c4e70dd5a04c503a2dab2ce2c0c74b2c6baa5921741

[tellaho]

@codex

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 30192c8d1f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[brow]

Thanks for the rewrite. Collapsing to a single pre-computed target id, filtering to rootId == null, and bounding the walk-back are all clear improvements, and the raw-timestamp forced-channel branch being gone closes the last open half of the earlier review. Reviewed at 9dd68e5e5.

Three issues below block merge for me. All three are behavior losses against the previous head a0aaa853b, and they share one root cause: the target model went from a set of unread ids to a single id, so whenever that one id is not reachable in the main timeline, the whole control disappears even though other genuinely-unread rows are loaded and on screen.

Each one has a passing control, an A/B against a0aaa853b, and a cause confirmed by mutating the specific line named (a red test alone would not prove the mechanism). All measurements are widget tests with fake message/channel/read-state notifiers driving the real _MessageList and the real buildMainTimelineEntries. No live relay, no real paged window responses, no device rendering.

1. Cap exhaustion suppresses the control even when an unread row is already on screen

message_list.dart:87-90 sets unreadBoundaryLoadFailed and returns, and :65 has that flag in the effect's early-return guard. So once the four-fetch cap latches, candidate resolution at :104-120 never runs again, and any other unread row already in entries is discarded.

fixture	head	fetchOlder() calls	chevron
two ordinary unread: one 5 pages back, one on the newest page	9dd68e5e5	4	absent
same fixture	a0aaa853b	5	present
control: only the on-screen unread	9dd68e5e5	0	present
control: only the on-screen unread	a0aaa853b	5	present

The controls pass on both heads, so the instrument separates the paths. This is the case I care most about, because it needs nothing unusual: just more unread history than four pages, which is the exact scenario the bounding was added for. The user has unread mail visible on screen and is offered no way to navigate to the boundary.

2. One unreachable target id suppresses the control for every other unread row

No pagination involved. If the snapshotted oldest-unread id cannot appear in the main timeline, oldestUnreadMessageId (message_list.dart:120) stays null permanently.

My fixture uses deletion as the vehicle: all rows loaded, reachedOldest == true, two ordinary unread events, and a kind:5 targeting the older one so formatTimeline drops it (deletion targets collected at timeline_message.dart:340-350, row skipped at :357). Chevron absent at 9dd68e5e5, present at a0aaa853b. Identical fixture minus the deletion: present on both heads.

Deletion is just the easiest way to construct it. Nothing prunes a deleted id out of observedUnreadEventsByChannel: the only removals I found are the catch-up cap eviction (unread_badge/observed_unread_event.dart:50-61) and read-coverage clearing (channels_provider.dart:757-768), neither of which is deletion-aware. Searched within mobile/lib/features/channels/. The general hazard is any snapshotted id that buildMainTimelineEntries will not admit.

3. A mixed ordinary plus forced target jumps to the wrong message

message_list.dart:82-83, hasLoadedKnownTarget = hasLoadedOrdinaryTarget || hasLoadedForcedTarget. An already-loaded forced msg: target satisfies the loop-exit test at :84-86 even when the known ordinary oldest-unread target is older and still unloaded. The walk-back never runs, and candidates at :118 then holds only the forced message.

Fixture: three pages, ordinary oldest-unread on page 1 (two pages back), a forced msg: unread on the newest page. Probe: 0 fetchOlder() calls, tap lands on the newest-page message. Control with the forced target removed: 2 calls, lands on the correct oldest message. At a0aaa853b the same fixture lands on the correct message. The latch is permanent: the target stays wrong after the older page arrives. If the ordinary target happens to be in the first window already, targeting is correct, so this needs the ordinary target outside the initial window.

Worth noting that _loadDeepLinkEvents (channel_detail_page.dart:251-272) now also preloads the ordinary target by id, which could pin it into the window and mask both this and issue 1 in practice. I could not measure whether that preload wins the race, so I am not relying on it either way.

Suggested direction

I tried this locally and it clears issues 1 and 2, with your checked-in suite unchanged at 71 passing and flutter analyze clean:

• Keep the single id as the fetch target, but resolve the displayed candidate from the reachable set rather than requiring that one id.
• Scope the give-up latch to fetching only, so exhausting the cap stops paginating but still selects from the rows already loaded.
• For issue 3, prefer the ordinary target when one is known, for example initialOldestOrdinaryUnreadMessageId != null ? hasLoadedOrdinaryTarget : hasLoadedForcedTarget in the loop-exit test.

Two smaller notes, not blocking:

• unreadBoundaryLoadFailed is set but never surfaced anywhere, so a bounded give-up is invisible to the user and to a test that is not looking for its absence.
• A test covering the deep-link-precedence and unread-boundary combination would be worth adding: a mutant in that interaction escaped the current suite.

Otherwise this is in good shape. The cap holds at exactly four even under repeated notifier rebuilds, threaded-only unread is a genuine no-op, rootId is provably the same discriminator as parentId here (nostr_models.dart:156-179) and matches main-timeline admission, and dropping the entries.first.message.id fallback correctly removes a false-positive chevron for a channel-level mark-unread with no unread messages. Happy to re-review as soon as you push.