trace: a step in split view moves the listing cursor to the pc

Normal navigation moves one pane and gives the companion a band, never a cursor
— that rule exists so the two can't chase each other. A trace step isn't
navigation: time is a single global position and both panes are showing the same
instant, so the cursor belongs on it in both.

_seek_split places the listing cursor on the current instruction, then hands off
to the existing _sync_split so the companion still gets its band and align() at
the driver's screen row. The anchoring machinery is used, not bypassed.

PARTIAL, and the shortfall is worth stating plainly: the LISTING cursor tracks
the pc reliably (tested over consecutive steps). The PSEUDOCODE cursor only
follows when decomp_map covers that address, and for cat's main it covers almost
nothing — four entries for a 700-line function. That is not something this
commit introduced and not something I could fix responsibly without
understanding it; TODO has what I measured, including that dec.goto(96) left the
cursor at 0 in the same run, which may or may not be the same bug.

One real fix along the way: _place_decomp_at prefers the map the trail painting
keeps (keyed to the decompiler's currently loaded function) over the split
view's _split_ea2line. The latter is refreshed by a guarded async path that
drops its result if _cur moved while in flight, and a burst of steps moves _cur
constantly — so during stepping it is frequently a map of the function you just
left.

tests: +2 trace UI (25) — stepping in split moves the listing cursor onto the pc
for six consecutive steps, and the trail marks it 'now' in both panes. 212/0
scenarios.

1 files changed, 23 insertions, 0 deletions

diff --git a/tests/test_trace_ui.py b/tests/test_trace_ui.py
index a43c11d..7ffe20f 100644
--- a/tests/test_trace_ui.py
+++ b/tests/test_trace_ui.py
@@ -208,6 +208,29 @@ async def run() -> int:
                 check("and so does stepping backward",
                       app._active == "decomp", f"active={app._active}")
 
+            # -- split view: a step is a GLOBAL move ------------------------ #
+            # Normal navigation moves one pane and gives the companion a band,
+            # never a cursor, so the two can't chase each other. Time isn't
+            # navigation though: both panes show the same instant, so the
+            # listing cursor must sit on the current instruction.
+            app.action_toggle_split()
+            await pilot.pause(2.0)
+            if not app._split:
+                check("split view toggled on", False)
+            else:
+                base = t.first_execution(main_ea) or 0
+                tracked = 0
+                for k in range(2, 8):
+                    app._seek(base + k)
+                    await pilot.pause(0.5)
+                    if lst._cursor_ea() == t.ip(app._t):
+                        tracked += 1
+                check("stepping in split moves the listing cursor to the pc",
+                      tracked == 6, f"{tracked}/6 steps tracked")
+                check("and the trail follows in both panes",
+                      lst.trail.get(t.ip(app._t)) == "now",
+                      f"{lst.trail.get(t.ip(app._t))}")
+
     print(f"\n{PASS} passed, {FAIL} failed")
     return 1 if FAIL else 0