[BUG] Fullscreen history view intermittently omits entries when scrolling back down after a deep scroll-up

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest are #56546 fullscreen janky scrolling and #72215 fullscreen scrolling broken; neither describes entries vanishing with the layout closed up)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

In fullscreen mode, after wheel-scrolling far up past the top of the visible history and riding back down, the re-rendered view intermittently omits one or more consecutive entries. Two flavors:

1. Closed-up omission (most common): the entries above and below the missing ones are seamed together with no gap. Frozen example: "✻ Crunched for 5m 40s" flows directly into "● Both tracks are in flight..." while the five entries between them (a background-command completion, an assistant message, a tool summary, two more completions) are simply not rendered.
2. Blank band: an empty region of rows where a tool batch should render, painted content above and below.

Scrolling another tick sometimes repairs the view. A sticky variant survives small scrolls in both directions and repairs only after ctrl+End followed by scrolling back up - at which point every missing entry renders correctly, so the history model still holds the content; the scrolled-window emission skipped it.

What Should Happen?

Every history entry should render at every scroll position; entries between two visible neighbors should never be omitted or replaced by blank rows.

Error Messages/Logs

N/A - silent rendering omission, no error output.

Steps to Reproduce

1. Fullscreen mode ("tui": "fullscreen"), Windows, a session with a few hundred KB of TUI output.
2. Wheel-scroll up 150+ notches, past the top of the loaded history.
3. Ride back down in ~15-notch steps, inspecting each stop.
4. Watch for an entry missing between two seamed neighbors, or a blank band. The omission is probabilistic (roughly 1 in 4-6 up/down passes); repeat the cycle a few times.

Reproduces with a real mouse wheel and with programmatically injected SGR wheel reports (\x1b[<64;x;yM / \x1b[<65;x;yM), during active streaming turns and on idle completed history, at multiple grid sizes (tested 210x48 and 306x15).

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown - reproduced and frozen on both 2.1.220 and 2.1.221, so not introduced by 2.1.221.

Claude Code Version

2.1.220 (Claude Code) and 2.1.221 (Claude Code) - both reproduced

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other (embedded xterm.js host under node-pty/ConPTY; Windows 11 build 26200)

Additional Information

Evidence that the omission is in the CLI's output, not the terminal displaying it: capturing the raw PTY output stream (independently of any display) and parsing it shows the missing entries' bytes are never emitted at that scroll position - the parsed capture matches the on-screen state exactly, including the omission, with both neighboring entries present. After ctrl+End + scroll-up, the same entries are emitted and render correctly, so the history model retains the content and the scrolled-window emission skipped it.

The scrolled history is visibly a live re-render (spinner verb labels re-roll between visits to the same region, e.g. "Cooked for 32s" -> "Crunched for 32s"; tool summary lines occasionally recompose between renders), which points at the window-assembly step skipping entries under scroll rather than data loss - consistent with the ctrl+End repair restoring everything.

CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1 plausibly masks the bug by removing incremental updates from the path (validating separately). If confirmed, the defect is specific to incremental-update emission for scrolled views.

Screenshots of both flavors are available - will attach on request.