hermes - 💡(How to fix) Fix [Bug]: Dashboard Chat wheel events can be swallowed before reaching xterm scrollback handler [2 pull requests]

Bug description

Current main already uses browser/xterm scrollback for Dashboard Chat and has an xterm custom wheel handler that calls term.scrollLines(...). However, the wheel handling is attached through xterm's own listener path only.

In browser/dashboard layouts, parent layers or renderer/host event ordering can consume or bypass wheel events before xterm's wheel handler runs. In that case, Dashboard Chat transcript scrolling with the mouse wheel can still fail even though keyboard scrollback and xterm scrollback itself are available.

Expected behavior

Mouse-wheel gestures over the Dashboard Chat terminal should reliably scroll the xterm transcript scrollback, including resumed chats / long transcripts, without forwarding wheel input into the PTY.

Actual behavior

Wheel gestures can fail to scroll the transcript when the event does not reach xterm's custom wheel handler.

Scope notes

• This is a narrow follow-up to the older broad wheel issue #19084, which is closed.
• This is not the older scrollback: 0 / inner-TUI-owned-history problem. Current main already has scrollback: 5000 and uses term.scrollLines(...).
• The narrow fix is to add a non-passive capture-phase wheel listener directly on the Dashboard Chat terminal host that calls the same xterm scroll helper as the existing custom wheel handler.
• Related PR: #29975.

Environment where observed during original investigation

• Hermes Dashboard Chat web TUI
• Hermes running in Docker/WSL on Windows 10
• Chrome browser accessing the dashboard

The proposed/current PR fix is scoped to the browser Dashboard Chat host and does not change native CLI/TUI mouse behavior.