TUI: drag-to-copy edge autoscroll scrolls ~3x too fast and glides after release

Summary

While drag-selecting, holding the cursor at the top or
bottom edge of the chat pane scrolls far faster than one line per tick, and keeps
drifting after the mouse button is released.

Repro

1. Run the TUI with a transcript taller than the viewport.
2. Press and drag below the last visible line (or above the first) and hold.

Expected: browser-like continuous scroll, roughly one line per tick, stopping on
release.
Actual: ~3 lines per frame (about 180 lines/s at 60fps), plus a short momentum
glide after release.

Root cause

progress_copy_selection_edge_autoscroll (app/copy_selection.rs) routes through
scroll_copy_selection_pane -> enqueue_mouse_scroll (app/navigation.rs), which
is the mouse-wheel momentum path:

• velocity multiplier: gap <= 30ms means 2x. A 60fps tick is ~16ms, so every
  autoscroll tick was classified as a hard flick.
• intent becomes min(3 * 2, 5) = 5 lines, added to a queue capped at 30.
• each call drains up to 3 lines, and mouse_scroll_drain_amount drains 3 more
  per frame while the queue is >= 6.

The queue therefore saturates at 30 and drains a flat 3 lines per frame. On
release the leftover queue keeps draining at 3/frame for ~10 frames, which is the
glide.

A programmatic per-tick scroll was being fed through a human-flick model.

Proposed fix

Give the drag autoscroll its own per-line step instead of the wheel queue, and
define its rate by a fixed tick cadence so it does not inherit redraw_fps.
Details in the PR.

Start in app/copy_selection.rs at progress_copy_selection_edge_autoscroll and trace its call into scroll_copy_selection_pane and enqueue_mouse_scroll in app/navigation.rs. Reproduce with a transcript taller than the viewport, then verify edge scrolling advances about one line per tick, is independent of redraw_fps, and stops immediately on release.