fix: preserve sidebar scrolling while streaming

[Michaelyklam]

Thinking Path

• Hermes WebUI should keep the left session sidebar usable while a long assistant turn streams.
• Issue bug(streaming): session-list sidebar cannot be scrolled while a chat is streaming — auto-scroll guard from #1731 is over-broad #1784 reported that the chat-pane pin-to-bottom path from the bug(streaming): small upward scrolls during streaming are overridden until user escapes near-bottom threshold #1731 family can fight scroll gestures outside the chat pane.
• I reproduced the root primitive in a clean origin/master worktree: a sidebar wheel gesture followed by the next scrollIfPinned() call forced #messages.scrollTop from 0 to the chat bottom (3073 in the fixture).
• The fix keeps the existing chat auto-scroll behavior, but records recent wheel/touch scroll intent outside #messages and skips only that immediate programmatic chat-pane scroll write.
• The session list also gets its own scroll boundary so sidebar gestures do not chain into the body/chat surfaces.

What Changed

• Added passive capture listeners for wheel and touchmove that record recent non-chat-pane scroll intent without calling preventDefault().
• Updated scrollIfPinned() to return early for a short 350ms window after a non-message scroll gesture, preventing token-render auto-scroll from fighting sidebar scrolling.
• Added overscroll-behavior-y: contain and touch-action: pan-y to .session-list.
• Added regression coverage in tests/test_streaming_sidebar_scroll.py.

Why It Matters

Users often browse or switch sessions while a long response is still streaming. The chat pane can keep its normal pinned behavior when the user is watching it, but sidebar scroll gestures should remain independent and responsive.

Verification

• Reproduced before fix on clean origin/master (9875967): sidebar wheel + next scrollIfPinned() moved #messages.scrollTop from 0 to 3073.
• Browser QA after fix in isolated local WebUI server (127.0.0.1:18784) with a synthetic 180-session sidebar and active streaming session:
  • after sidebar wheel + immediate scrollIfPinned(): #messages.scrollTop stayed 0
  • after guard expiry + scrollIfPinned(): #messages.scrollTop moved to 2992
  • .session-list computed CSS: overscroll-behavior-y: contain; touch-action: pan-y
• python -m pytest tests/test_streaming_sidebar_scroll.py -q → 3 passed
• python -m pytest tests/test_streaming_sidebar_scroll.py tests/test_streaming_markdown.py::TestExistingStreamingGuardsIntact -q → 10 passed
• git diff --check → passed

UI media / evidence:

Structured QA evidence: https://raw.githubusercontent.com/Michaelyklam/hermes-webui/fix/issue-1784-sidebar-scroll-streaming/docs/pr-media/1784/sidebar-scroll-qa.json

Fixes #1784

Risks / Follow-ups

• The guard is intentionally short and only affects scrollIfPinned(), not explicit scrollToBottom(), so a user click on the bottom button still restores the chat pane immediately.
• If WebKit reports touch targets differently than Chromium, the passive document-level capture listener should still see the original sidebar descendant target before any bubbling handlers run.

Model Used

• Provider: OpenAI Codex
• Model: gpt-5.5
• Tool use: Hermes CLI agent with terminal, browser QA, file editing, pytest, git, and GitHub CLI.

[nesquena-hermes]

Thanks @Michaelyklam — this shipped in v0.51.18 (commit a8de4e7) as part of a 5-PR full-sweep batch. Stage rebased your branch onto current master, ran the full pre-release gate (4733 pytest, browser tests, Opus advisor verdict SHIP all 5), and merged via release PR #1799.

GitHub didn't auto-close because the merge commit only references the squash-merged stage branch, not your fork's commit directly — closing manually for hygiene.

Live now on existing installs after git pull + restart.

Release notes: https://github.com/nesquena/hermes-webui/releases/tag/v0.51.18