decomp: drop stale navigation results so Esc isn't silently undone

Esc in the pseudocode view appeared to jump back and then not update until you
pressed something else. It wasn't a repaint problem (my previous commit guessed
that and fixed a different, real, but unrelated staleness): the Esc WAS being
undone.

_do_navigate decompiles on a worker thread and hands the result to
_open_decomp_entry, which applied it unconditionally. Decompiling a large
function takes a moment, so pressing Esc while it's in flight meant the late
result landed afterwards and re-applied the forward navigation — putting you back
where you'd just left. The next keypress then made things look "correct" again,
which is exactly the reported symptom.

Add a navigation sequence number: _do_navigate captures it when it starts,
action_back bumps it, and _open_decomp_entry drops a result whose sequence no
longer matches.

Verified both ways on a slow target (sub_3720): Esc pressed 20ms into the
navigation now stays back at main:60, and removing just the guard reproduces the
bug exactly (cursor=0, loaded=0x3720 — the function being left). Suite 192/0,
project UI 23/23.

0 files changed, 0 insertions, 0 deletions