fix: hold the scroll position when older events load above

[chasers]

Follows #3986. Reported on staging: clicking "Load more" at the top moves the viewport, and the jump is obvious when a log line wraps to several lines.

Cause

#logs-list is flex-direction: column-reverse, so the top button inserts older events at the visual top and pushes every row below them down.

Two things moved the scroll on that load, and neither knew about the other:

1. updated/0 ran restoreScrollAnchor/0, holding the visible row in place.
2. put_event_page/3 pushed scroll-to-event, jumping the oldest new row to the top.

Both ran inside requestAnimationFrame, so whichever fired second won. A following diff (the URL patch, the chart, the buttons) ran the anchor restore again. updated/0 guarded the restore for scroll-to-bottom only, so scroll-to-event never got that discipline.

Both failure modes scale with the height of the inserted batch, which is why wrapped lines made it visible and single lines did not.

Fix

• Drop push_scroll_to_oldest/2 and the scroll-to-event push. Nothing else used that event, so the hook handler goes too. The anchor restore is now the only owner of the scroll on a page load.
• Stop falling back to window.scrollTo(0, this.scrollPosition). That offset is stale once rows land above the viewport, and it was wrong by exactly the height of those rows.
• Keep an anchor only when the row carries an id.

Tests

The "anchor row is gone" test fails against the old fallback and passes against the fix. I verified both directions.

• 226 Elixir tests pass across the 5 affected files
• 70 JS tests pass
• format, lint.all, test.slop (27/29) and test.structure pass

Please confirm on staging with a source that has wrapped log lines.

🤖 Generated with Claude Code

[chasers]

Reproduced on staging, and the fix measured at zero drift

Attached Playwright to a real Chrome over CDP against test.logflarestaging.com, source 58, t:2026-09-17T09:{26..30}:00, US/Arizona. 100 rows on screen, 100 added per click, tallest row 195px, median 20px.

As deployed

driftPx 2408    anchorTop 459 -> 2867    scrollY 0 -> 225

Timeline:

t=1151  y=4     scrollBy [0, 2628.5]      <- anchor restore, correct
t=1152  y=2633  scrollIntoView log-...    <- scroll-to-event, wins
t=1177  y=225                             <- lands 2408px off

restoreScrollAnchor/0 computes the right compensation and applies it. One millisecond later scroll-to-event runs scrollIntoView({block: "start"}) on the oldest new row and overwrites it. That is the race this PR removes.

With scroll-to-event suppressed, which is exactly what this PR does

driftPx 0    anchorTop 459 -> 459    scrollY 0 -> 2633

The row the reader was on does not move.

Note for reviewers

This does not reproduce against a local dev source. There document.getElementById(id) returns null, so the ?. swallows the call and the jump never happens. You need a source where the oldest row's dom id resolves, which staging has.