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, 29 insertions, 0 deletions

diff --git a/TODO b/TODO
index 90da191..679318c 100644
--- a/TODO
+++ b/TODO
@@ -88,3 +88,32 @@ The general rule this came from: a suite whose result depends on its own history
 can't be trusted to accuse the code. tests/test_blob_ui.py builds a throwaway
 binary; test_project_ui.py stages copies; test_thumb_ui.py deletes the .i64
 before each phase because the T flag and segment bitness are SAVED in it.
+
+## decomp_map returns almost nothing for some functions (blocks split stepping)
+
+Found while making a trace step move BOTH cursors in split view. For cat's
+main() — 700+ pseudocode lines — decomp_map() came back with FOUR entries, so
+almost no instruction address maps to a C line and the pseudocode cursor can't
+follow the program counter. On echo's main the same call maps plenty (the trail
+painting test relies on it), so it is function- or timing-dependent, not simply
+broken.
+
+Two things to separate when picking this up:
+
+* Is the map itself sparse (the tool's item.dstr() walk missing most items for
+  this function), or is it being FETCHED at a moment when the decompiler has a
+  different function loaded? _trail_map_ea and dec.loaded_ea both read 0x24a0
+  when it happened, which argues for the former.
+* dec.goto(96) left dec.cursor at 0 in the same run. That may be a symptom of
+  the same confusion (a stale/short _strips) or an independent bug. Check it on
+  its own before assuming.
+
+Also noticed: _split_ea2line is refreshed by a guarded async path
+(_apply_split_map drops its result if _cur moved while in flight). A burst of
+trace steps moves _cur constantly, so during stepping it is frequently the map
+of the function you just left. _place_decomp_at now prefers the trail's map for
+that reason, but the split view's own sync still uses the laggy one.
+
+Consequence today: in split view a trace step moves the LISTING cursor onto the
+current instruction (works, tested) but the pseudocode cursor only follows when
+the map happens to cover that address.