The older-page cursor is unguarded: dropping it leaves the renderer suite green

Filed by cycle cyc20260921-051840 while reviewing #1489 (the GUI half of rant
2026-09-20T18:58:44). Not a defect in that PR — its code passes the cursor correctly, and the
library-level cursor semantics are well pinned. This is the missing guard between the library
and the component, measured with a mutation arm.

Measured

On #1489's head ba14a18f (renderer suite at the head: 46 files, 537 passed):

emrg/gui/renderer/src/components/Shell.tsx, loadOlderHistory:
  -        includeRecords: true,
  -        beforeIndex: st.oldestIndex,
  +        includeRecords: true,

  npm test  →  46 files, 537 passed, 0 failed

Nothing goes red. The older-page request therefore has no test asserting it carries the cursor.

Why it matters

Shell.test.tsx:181 is the file's only history case and it exercises the first page only
(includeRecords: true, no beforeIndex). history.test.ts covers the pure logic
(oldestIndex advances, overlap dropped by loaded, an empty page forces has_more=false).
Between them sits the wiring, and that wiring is the whole of the rant's defect 3 — paging
repeated, skipped and stranded records.

If a later edit drops beforeIndex, the behaviour that returns is exactly the reported symptom,
quietly: scrolling to the top re-fetches the newest window, unloadedRecords filters all of it out
because those records are already in loaded, and applyHistoryPage resets oldestIndex to the
same value it already had — so "load more" never advances and earlier content stays unreachable,
with a green suite and green CI.

What would close it

One case in Shell.test.tsx, in the shape of the existing one: load the first page, scroll the
transcript to the top (onLoadOlder / a scrollTop = 0 dispatch, as TranscriptView.test.tsx:291
already does), and assert the second listHistory call is
expect.objectContaining({ includeRecords: true, beforeIndex: <the oldest record_index of page 1> }).
That case must go red under the mutation above.

A second, smaller case would pin the other half of the same wiring: that page 2's records are
prepended as one block (replayHistoryRecordsPrepend) and page 1's are not re-appended — the
prependEntries / shiftIndexes path added by the same PR, which today is exercised only through
the scratch-store unit and not through Shell.