GTK: scroll wheel only works on focused tab group

[JDonaghy]

Symptom

In the GTK build, when there are multiple editor groups (e.g. Ctrl+\ to split right), the scroll wheel only scrolls the focused group. Hovering the mouse over a tab in the unfocused group and scrolling does nothing — you have to click into that group first.

The TUI build behaves correctly: hover over any window in any group and the wheel scrolls that window without changing focus or moving the cursor.

Cause

src/gtk/mod.rs:4048 (Msg::MouseScroll handler) calls engine.scroll_down_visible(...) / scroll_up_visible(...), which always operate on the active window's view. The TUI handler at src/tui_main/mouse.rs:1316 instead resolves the window under the cursor first and calls engine.scroll_*_visible_for_window(window_id, count).

The GTK scroll handler also has no access to the pointer position — Msg::MouseScroll { delta_x, delta_y } only carries deltas, not coordinates.

Fix

Two parts:

1. Track the editor pointer position via a small EventControllerMotion on the editor DrawingArea, storing (f64, f64) in an Rc<Cell<Option<(f64, f64)>>> field on App. Reset on connect_leave.
2. In Msg::MouseScroll, read the cached pointer, walk engine.calculate_group_window_rects(...) (same call pixel_to_click_target uses) to find the window under it, and call scroll_*_visible_for_window(window_id, count) when that window isn't the active one. Active window keeps its current cursor-clamp behaviour.

Acceptance

• Open vimcode, split right (Ctrl+\), focus group A, hover the wheel over group B → group B scrolls
• Hovering over group A still scrolls group A
• Hovering over the tab bar / outside the editor area still triggers no scroll (no fall-through to active window)
• No regression to TUI scroll behaviour (no changes to tui_main/mouse.rs)

[JDonaghy]

Implemented in 9e50f5a