[Feature]: Introduce virtual scrolling for Console WebUI to resolve performance degradation with long conversations

## Summary

Introduce virtual scrolling (or paginated rendering) for the message list in the Console WebUI, so that the page remains responsive even when the conversation history grows long — resolving the severe lag caused by full DOM rendering of all messages.

## Component(s) Affected

- [ ] Core / Backend (app, agents, config, providers, utils, local_models)
- [x] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation

The Console WebUI currently renders the entire conversation history into the DOM at once. When conversations exceed ~100–200 messages, the number of DOM nodes can reach thousands or tens of thousands, causing:

1. **Scrolling lag** — every scroll event triggers expensive Reflow / Layout recalculations across thousands of nodes.
2. **Input latency** — typing in the message box can trigger full re-renders of the entire message list.
3. **Slow initial load** — refreshing or switching conversations requires rendering every message before becoming interactive.
4. **Worse on Edge** — Edge's built-in "Efficiency Mode" aggressively throttles CPU for the tab, compounding the issue.

This affects any user who regularly has long conversations through the WebUI, and has been widely discussed in similar products (e.g. Open WebUI, ChatGPT, Claude).

## Proposed Solution

Implement **virtual scrolling** in the Console frontend — render only the messages currently visible in the viewport, replace off-screen messages with empty placeholders, and dynamically create/remove DOM nodes as the user scrolls.

Specific suggestions:

- Use a proven virtual scrolling library such as `react-window`, `react-virtuoso`, or a lightweight custom implementation.
- Since message heights vary significantly (code blocks can be short or very long), use **dynamic height measurement** — either estimate before rendering or measure after first render and cache the height.
- Auto-scroll to bottom when a new message arrives; lazy-load older messages when scrolling up.
- Optionally combine with backend pagination (fetch history in chunks) for even better performance on very long conversations.

## Alternatives Considered

| Approach | Pros | Cons |
|---|---|---|
| **Pagination** (load 20 messages at a time, click "Load more") | Simple to implement, works immediately | Less fluid UX, requires manual action |
| **Message archiving / summarization** (collapse old messages into summaries) | Reduces DOM while preserving context | Requires extra AI summarization logic, adds complexity |
| **Hard limit on rendered messages** (e.g. show only last 50) | Trivial to implement | Loses access to earlier history, poor UX |
| **Advise users to start new sessions** (current practice) | Straightforward | Not a product-level fix; interrupts workflow |

Virtual scrolling is the standard approach used by ChatGPT, Claude, and Open WebUI — it balances performance and user experience without sacrificing functionality.

## Additional Context

- **Browser/OS tested:** Microsoft Edge (Chromium) on Windows 10. Reproducible with ~150+ messages.
- **Mitigation tested:** Switching to Firefox helps somewhat (Firefox's Quantum CSS parallel layout and absence of an aggressive Efficiency Mode delay the onset of lag), but is not a root fix.
- **References from similar projects:**
- [Open WebUI #13787: UI is extremely slow with large chat history](https://github.com/open-webui/open-webui/discussions/13787)
- ChatGPT, Claude, and other mainstream chat UIs all use virtual scrolling for their message lists.

## Willing to Contribute

- [ ] I am willing to open a PR for this feature (after discussion).