split: keep _active in step with focus, so Enter follows the pane you're in

Reported as "Esc in the decompiler needs two presses". It was never Esc.

In split mode Tab sets _active AND focus together, but focus also moves on its
own — a click, or a pane focusing itself after a load — and _active was left
naming the pane you are NOT in. Everything downstream trusts _active, so with the
pseudocode on screen and the listing still "active", Enter resolved the word
under the LISTING's cursor: it followed something unrelated (typically the outer
function itself, landing on line 0 col 19 — its own name in the prototype) and
pushed history for it. The first Esc was then spent undoing that bogus entry and
looked like a no-op; the second did what you meant.

on_descendant_focus now syncs _active to the focused code view while split, the
same pair of steps Tab already does (set _active, re-link the band, restatus).

Verified on a live pane driven through tmux, which is the only harness in this
session that told the truth — the in-process pilot never exercised follow-then-Esc
in split, which is why four earlier attempts "passed" while the bug sat there:

  before: Enter on sub_3500 -> fn main,      L0   (never left the function)
  after:  Enter on sub_3500 -> fn sub_3500,  L0   then Esc -> main L54, one press

Suite 192/0.

Known remainder, deliberately not fixed here: a follow still pushes two entries
(nav 2 -> 4), so the stack is deeper than it should be. Landing is correct at
every step, so it isn't visible as the reported bug. The obvious dedupe in
_open_decomp_entry (skip appending src when the top entry is the same place) is
inert — the duplicate comes from somewhere else, and I'd rather leave it open
than commit a fix I can't show working.

0 files changed, 0 insertions, 0 deletions