split: propagate pure scrolls (wheel/scrollbar) to the companion pane

The sync only ran off CursorMoved, so a wheel-scroll or scrollbar drag — which
moves the viewport but never the cursor — left the other pane behind.

* ListingView/DecompView post a new Scrolled message from watch_scroll_y when the
  rounded scroll changes; the app re-syncs on it (guarded to the active pane, so
  a companion's align() can't feed back).
* _split_anchor(view): the sync now anchors on the driver's cursor while it is
  visible, else on the top visible row. Cursor moves behave exactly as before
  (key-nav always scrolls the cursor into view); once a pure scroll takes the
  cursor off-screen the viewport itself becomes the anchor, so the companion
  keeps following what you're actually looking at — including re-decompiling as
  you scroll across function boundaries.

Pilot split_view gains a pure-scroll check (viewport moves, cursor doesn't, the
companion still moves): 20/20. Full suite 167/2-flake.

Three existing checks were setting .cursor without scrolling it into view, which
the anchor correctly treats as "cursor not visible"; they now scroll like real
key-nav. The multi-region check also had to make the decomp the ACTIVE pane
before a decomp-driven sync — otherwise the companion's align() fires Scrolled
and re-syncs listing-driven, clobbering the link (impossible in real usage, where
the companion is by definition not the active pane).

0 files changed, 0 insertions, 0 deletions