trace: stepping stays in the view you're reading

Caught while demoing this in a live pane, not by a test: press Tab to read the
pseudocode, press ] once, and you're back in the disassembly.

_seek() follows the trace by navigating to the new PC, and navigating to an
ADDRESS opens the listing unless the decompiler is explicitly preferred. So
every step out of C dropped you out of C — the painting work of the last commit
was unusable in the view it was built for, from the first keypress.

_seek now passes prefer_decomp=(self._active == "decomp"), the same thing the
xref handler already does for the same reason.

Worth noting what it looks like when it works: stepping in pseudocode follows
execution INTO a callee and the view switches to that function's C, which is
what you want and what makes the decompiler painting worth having.

tests: +2 trace UI (23) asserting the view survives a step in both directions.
212/0 scenarios.

0 files changed, 0 insertions, 0 deletions