Conversation area becomes unscrollable past a rolling window once a session grows large, older content permanently unreachable

Environment: VS Code extension v2.1.241, macOS.

What happened: In a long-running session, the conversation area stopped responding to scroll (trackpad) while idle (not actively streaming — this is distinct from the known auto-scroll-lock-during-generation issues, e.g. #11578, #58767). Scrolling up from the bottom stops at a specific point partway through the session; everything older than that point is unreachable. This is also distinct from #68732 ("scroll does not work in conversation area"), whose own reporter noted that bug was explicitly unrelated to conversation length — this one specifically correlates with length/size.

Measured, from the session transcript (~/.claude/projects/<project>/<session-id>.jsonl):

| | Timestamp | Elapsed from session start | Turn-level messages so far | Transcript size so far |
|---|---|---|---|---|
| Session start | 2026-08-23T12:46:06Z | — | 0 | — |
| Furthest point reachable by scrolling up | 2026-08-23T16:47:26Z | ~4h01m | 182 | ~1.56MB |
| Point of this report (scroll still stuck at the same boundary) | 2026-08-23T22:13:12Z | ~9h27m | 720 | ~4.3MB |

This looks like a rolling window, not a total-length cap. The reachable range is roughly the most recent ~538 turn-level messages / ~2.75MB — older content silently falls out of scroll range as the session keeps growing, rather than the whole history staying reachable and scrolling merely becoming slow. The boundary did not move forward as more messages were added; it stayed pinned at the same message from ~4h01m in, even ~5.5 hours and 538 more messages later.

Expected: The conversation area remains scrollable to the full session history regardless of length, or — if there's a deliberate virtualization window for performance — older content should still be reachable (e.g., via progressive loading on scroll) rather than becoming permanently unreachable.

Actual: Once the window's boundary is set, it appears fixed — content older than the boundary is not reachable by scrolling, with no visible indication that a limit was hit (no "load more" affordance, no truncation notice).

Note: I don't have an exact message-count or byte-size threshold that triggers this — the numbers above are what was measured in this one session, not a controlled minimum repro. Happy to provide the full session transcript privately if useful for characterizing the actual threshold.