fix: stop long sessions ratcheting into full-transcript re-renders

[alanjds]

Split 1 of 4 from a combined branch (alanjds/hermes-webui#2). Affects the default path (virtualize_transcript off) — this is the one that removes the cliff.

Problem

renderMessages() rebuilds the whole transcript and runs on every send, every SSE batch and every refresh. On a synthetic 2000-message session (desktop Chromium; a phone is several times slower), with the shipped default virtualize_transcript=false:

loaded rows	render	DOM nodes
37	46 ms	960
537	546 ms	13,460
2000	2,883 ms	50,007

Cost tracks S.messages.length exactly. The server is not involved — Session.load() is 4.6 ms and GET /api/session ~330 ms flat at both 200 and 2000 messages. So the bug is whatever loads the whole transcript into the browser.

Two things did, and together they formed a one-way ratchet nothing undid short of a page reload.

1. The bare full-transcript refetch

_messageReloadLimitForSession() returned null — "send no msg_limit" — when the previous load wasn't truncated, or when the reload hint exceeded the server ceiling. The hint grows to the loaded row count, so paging back crossed the 500-row ceiling and from then on every same-session refresh (tab focus, SSE catch-up, visibility change — which fire aggressively on mobile) refetched and re-rendered all 2000 rows.

That null was deliberate: a clamped window would silently drop already-loaded older rows (nesquena#6152/nesquena#6154). The window is now always bounded, and the invariant is upheld differently — rows older than the returned window that we already hold are retained and re-prepended.

The re-join is skipped, letting the server window win, when the prior rows can't be trusted to line up: the session shrank server-side (fork / undo / truncate), or we don't hold enough rows to cover the gap. Losing older rows to a re-fetch is recoverable via "load earlier"; splicing a stale prefix onto a rewritten transcript is not.

loadSession() clears S.messages and _oldestIdx before the reload fetch, so the pre-clear offset is stashed alongside the existing carry-forward snapshot and consumed with it.

2. The render-window ratchet

nesquena#6999 capped the auto-expanding render window at 4× the default, but the two stream-completion sites in messages.js still expanded it to every loaded row — one completed turn undid the cap. All three sites now share one bounded helper.

This restores the nesquena#6999 invariant; it does not by itself bound render cost (with virtualization off the DOM is built for every loaded row regardless). Part 1 is what removes the cliff.

Deliberately out of scope

The render window is also expanded to the full transcript by jump-to-session-start, jump-to-message when the target is outside the window, and the outline jump; and outline.js still issues a bare no-msg_limit fetch. Those are explicit user requests to reveal the whole transcript, addressed by absolute index — windowing them needs a jump-to-index-with-context fetch.

Verification

• Reload requests always carry msg_limit, verified by intercepting the page's real /api/session traffic.
• Render window stays at the 200 cap across repeated turn completions.
• Targeted suite green on current master. Note the full tests/ run is too flaky to use as a signal — ~45–50 failures on both this branch and pristine master, differing in both directions, all in test_workspace_git.py / test_webui_state_db_reconciliation.py.

test_webui_external_refresh_frontend.py pinned the exact source strings this changes; those assertions are updated to the new mechanism, plus two new tests (the retained-prefix re-join and its bail-outs; no expansion site still using the raw uncapped count).