decomp: repaint on a same-viewport jump (Esc back looked like it did nothing)

Esc in the pseudocode view navigated correctly but the pane kept showing the old
cursor line until you pressed something else. The listing view was fine because
its path goes through load(), which relayouts and repaints.

DecompView.goto() sets `cursor`, which is reactive(repaint=False), and then
leaves redrawing to _apply_scroll — but that only repaints via
call_after_refresh, which needs a refresh to actually happen. Jump somewhere
inside the viewport already on screen (exactly what Esc-back within a function
does) and the scroll doesn't change, so nothing asked the widget to redraw: the
old highlight stayed and the status line had already updated, which is why it
looked like the jump half-worked. _move() doesn't hit this because it repaints
the old and new rows via _refresh_lines.

goto() now refreshes explicitly.

Verification note: a render_line-level probe CANNOT see this bug — render_line
reads self.cursor live, so it always reports the new position. The staleness is
in Textual's compositor cache, which only a repaint request clears. Verified by
spying on the widget's refresh instead: a same-viewport goto now requests one
(it requested none before). Suite 192/0.

0 files changed, 0 insertions, 0 deletions