fix: extend upward scroll intent timeout to prevent streaming scroll snap-back

[emanon312]

Problem

During streaming, users who scroll up to read earlier content get snapped back to the bottom — especially when they pause scrolling for a moment before the message finishes generating.

Root Cause

The MESSAGE_UPWARD_INTENT_MS timeout (_recentMessageUpwardIntent()) was only 450ms. The race condition:

1. User scrolls up during streaming → _scrollPinned = false ✓
2. User pauses scrolling to read (>450ms since last wheel event)
3. DOM layout changes from the streaming markdown parser (smd), tool card insertions, or code re-highlighting trigger scroll events
4. Handler no longer recognizes these as user-initiated (intent expired) → movedUp = false
5. If position lands inside the 250px near-bottom zone for 2 consecutive samples → _scrollPinned = true
6. Next streaming token → scrollIfPinned() → forces scrollTop = scrollHeight → snap!

This is particularly noticeable on long responses where the user scrolls up a small amount (still within 250px of bottom) and pauses to read.

Fix

Increase MESSAGE_UPWARD_INTENT_MS from 450ms → 2000ms.

This gives the user a 2-second protection window after their last upward scroll, during which DOM-triggered scroll events are correctly identified as co-occurring with user intent, preventing re-pinning.

What is NOT affected

• Downward scrolling still re-pins normally (movedUp requires top < _lastScrollTop - 2 which is false for downward movement regardless of intent timeout)
• Scroll-to-bottom button still works (scrollToBottom() directly sets _scrollPinned = true)
• macOS trackpad momentum protection (bug(streaming): auto-scroll still overrides user scroll position on macOS app — #677 regression / edge case #1360) is preserved
• Sidebar scroll isolation (bug(streaming): session-list sidebar cannot be scrolled while a chat is streaming — auto-scroll guard from #1731 is over-broad #1784) is preserved
• Session switch scroll reset (bug(streaming): small upward scrolls during streaming are overridden until user escapes near-bottom threshold #1731 follow-up) is preserved

Testing

No existing tests hardcode the 450ms value — the test suite validates the structural behavior (direction detection, unpin semantics, hysteresis thresholds) without depending on the specific timeout.

Refs: #1360, #1731

[nesquena-hermes]

Absorbed and shipped in v0.51.187 (Release FG) via #3271. 🎉

Thanks @emanon312 — clear diagnosis of the streaming snap-back, and the 450ms→2000ms intent window is the right lever (the direction check keeps downward re-pin and the scroll-to-bottom button unaffected). I added a regression test (test_issue3250_upward_scroll_intent_window.py) pinning the widened constant, that _recentMessageUpwardIntent() gates on the constant, and that downward re-pin stays independent of the window — so the tuning can't silently regress. Co-authored-by attribution preserved in the commit trailer.