fix(tui): prune messages on prompt submit instead of during streaming

[malventano]

I've been on a quest to fix the scrollback not staying in place while output and tool calls are happening below. I have a PR against opentui (#1088) that addresses the core sticky-scroll reset in recalculateBarProps, but it only fully corrects the issue so long as the session has fewer than 100 messages. Before that PR, when scrolled up while streaming output the pane would continue to scroll as lines were added to the bottom. With that PR the pane stays put, but once the session reaches 100 or more messages, while scrolled up, the pane will once again start jumping as older sections are pruned to maintain the 100-message limit.

After trying a few dozen ways to work around pruning while new tool blocks are being added below (including renderable-level scroll compensation tracking anchor child positions, which proved unreliable due to timing between Solid effects, Yoga layout, and \_translateY propagation, and a scrollHeight delta approach that failed because scrollHeight changes from content below mask the shrink from above), I got tired of fighting with workarounds and compounded assumptions. Compensating for messages pruned from the top while new content is added below is chasing a moving target.

This fix delays pruning until the user enters the next prompt. Messages are allowed to grow beyond 100 during the response, but are batch-pruned back to 100 when the next prompt is submitted. Since the user is likely at the bottom when hitting Enter (though not guaranteed), there's minimal risk of scrolling disruption. Opening other sessions still only loads the last 100 messages, so no memory concerns there, and I don't expect so much scrollbox growth during a single reply that would cause an issue.

Issue for this PR

Closes #7648
Addresses #7659

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

• Removes continuous one-by-one message pruning from message.updated event handler in sync.tsx
• Adds prune() method to session store that batch-prunes to 100 messages and cleans up associated parts
• Calls prune() in prompt submitInner() before sending the user message

How did you verify your code works?

Tested on local build with sequential file edits over streaming output, combined with opentui PR #1088 applied. Without that PR the pane would still scroll up during streaming, just not as quickly. Both fixes are needed for the pane to stay completely put while scrolled up. With both applied, scrolling up during a long streaming session shows no viewport jumps. Without this PR, jumps occur as messages are pruned mid-stream.

Screenshots / recordings

N/A -- terminal behavior

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍