flake fix: keep restored reading anchor out of bottom follow (WebKit scroll measurement)

[loganj]

Flake fix for main. The WebKit Browser measurements job failed in run 36583908128 (job 109458992105). In scroll.spec.mjs:97, after a reload, the saved anchor ended up 650px from its saved Y and the timeline was scrolled to the bottom. The previous main run (36581079093) passed. The only commit in between is #364.

Root cause

When ChannelTimeline restores a saved reading anchor, it scrolls with scrollToIndex before Virtua has measured the rows beneath that anchor. After #364 changed row grouping and heights, WebKit can deliver that restoration scroll event while the estimated list is still short: scrollTop=452 with scrollHeight=1140. recordPosition read that as bottom: true and set follow.current = true. The restore effect's cleanup only keeps the restoration while !follow.current, so the restoration was dropped. Each later measurement then pinned the timeline to the end.

Instrumented failing sequence (local WebKit):

effect  restore={offset:3416,bottom:false,anchor:{y:157.3}}
restorePosition scrollTop=0 scrollHeight=858
record  {offset:452,bottom:true,...} scrollHeight=1140   <- restoration scroll, not input
cleanup restore=true follow=true                         <- restoration dropped
effect  saved={bottom:true} restore=null                 <- now follows bottom

Fix

While a restored anchor is active (restoredAnchor is set and has not been cleared by reader input), recordPosition no longer marks the position as bottom follow. Reader gestures already clear restoredAnchor before they record a position, so moving to the bottom by hand still resumes follow.

This PR doesn't change any tests, timeouts or browser projects. It adds a unit regression test that fails without the fix.

Validation (local, macOS, Playwright 1.63 WebKit/Chromium)

• Base ae687c7c: scroll.spec.mjs:97 on webkit-measurements failed with the same Received: 650 in about 1 of 6 runs, plus 1 of 5 instrumented runs.
• With the fix (d8c40d33): scroll.spec.mjs:97 passed 12/12 isolated WebKit runs and 2/2 Chromium runs.
• Full chromium-measurements and webkit-measurements (CI config): 7 passed.
• initial-position, history-loading, image-scroll, new-message and messages on Chromium and WebKit: 56 passed.
• vitest run: 421 files, 5121 tests passed. The new test fails on the base.
• pnpm typecheck passed, and biome is clean on the changed files.

[wesbillman]

Star Lord — automated source review via Wes’s account

No actionable production defects found in this revision. Non-blocking source review, not approval or merge authorization.

• Head: d8c40d33bc2e257dfaf106e1c43560b6014d413b
• Base: 61da2662d74aeea46ea8344fb4dc6e247baaab68

The guard in ChannelTimeline.tsx:208 preserves non-follow reading intent while a restored anchor is active, before that observation reaches both savedPosition and follow. This also preserves the restore effect’s existing cleanup/correction path. Reader gestures clear the anchor before recording a new position; explicit message navigation and local-send reveal clear it as well. The ordinary bottom-follow path remains unchanged when no restored anchor exists.

I traced restoration, late row measurements, row refresh/cleanup, reader input, local-send reveal, and the Channels/Sessions callers. Separately checked the existing loading/error/retry and focused-row retention paths: this change introduces no new focus transfer or retry state; native focus/scroll behavior remains unexercised by this review.

Optional test follow-up: the new case uses the existing hook-mocked harness. AGENTS.md and docs/contributing.md direct new component lifecycle coverage to real React; the nearby ChannelTimeline.restore.test.tsx already provides that boundary. Moving this scenario there would cover React cleanup/rerender ordering rather than the substitute hook scheduler, without migrating the entire older suite. The new assertions do target the reported accidental-bottom-follow state; this is not an additional demonstrated production defect.

Public-material check: reviewed the two-file diff, the single commit message and the public PR description; no attached images were present and no internal coordination URLs, workspace identifiers or secrets were identified in those surfaces. Legitimate public links and commit authorship attribution are not treated as leaks.

Validation limits: source only; no PR code, tests, builds or app were executed. Reviewed immutable Git blobs, not live-working-tree content; git diff --check passed for the pinned comparison. The existing browser reload/append journey and the author’s reported WebKit/Chromium runs are relevant, but I did not reproduce them. One hosted-check snapshot showed DCO/Semgrep/zizmor passing, JavaScript/Rust/browser jobs still running, and Windows validation skipped. This does not establish CI completion, packaged/native correctness, or elimination of the WebKit flake.