trace: seek verbs — next/previous execution, and who set this register

M3. Stepping walks time; seeking jumps to the next time THIS thing was touched,
which is what makes a trace more than a very long single-step log.

`>` / `<` — next/previous execution of whatever the focused view addresses. One
pair of keys, two questions, because what's on screen already says which:

* listing: the instruction under the cursor. "When else did this run?"
* pseudocode: the whole C line, as the union of its instructions' executions. A
  line is not one address, and falling back to its single /*ea*/ marker would
  answer a narrower question — usually none at all, since most lines have no
  marker.
* hex: the byte under the cursor, via memory_accesses.

It says where you landed ("execution of 0x3160: 2 of 2 @ t=320") and, at either
end, that you're AT the end rather than silently doing nothing — a key that does
nothing is indistinguishable from a broken one.

`W` — the registers with the instruction that set each to its current value, and
the distance back. Enter seeks to that write, f seeks forward. Backward is the
direction people want: you notice a bad value after it has been used. This is
the question a trace exists to answer and it was already in the model
(last_write/next_write), untested in anger until now.

tests: +13 trace UI (38) — > and < move between the two executions of a
repeated instruction, the status names which execution it is, both edges report
instead of moving, W opens, and choosing a register lands on an instruction that
REALLY wrote it (checked against the trace's own changed-set, not just the
timestamp matching).

Two things the tests taught me, both recorded:
* focus() does not make a view active outside split mode — Tab does. My first
  seek test pressed > while _active was still "decomp", so it asked the
  pseudocode about a line with no instructions.
* TODO gets a new entry: a stray late navigation to the entry function arrives
  after a seek and wins, leaving the cursor on 'start' while the pc is
  elsewhere. Same shape as the stale-decomp-result bug fixed in 756589a, which
  got a sequence guard the listing path never did.

212/0 scenarios, 35/0 model, 12/0 differential.

1 files changed, 27 insertions, 0 deletions

diff --git a/TODO b/TODO
index cb8ad91..7a79ba8 100644
--- a/TODO
+++ b/TODO
@@ -114,3 +114,30 @@ same thing, fetched separately and keyed differently — the split one on _cur (
 cursor's function), the trace one on the decompiler's loaded function. That is
 how they ended up describing different functions. There is now one index, keyed
 to what the decompiler HOLDS, and both read it.
+
+## A stray navigation to the entry point during trace seeking
+
+Seen while building M3. After a trace seek, a SECOND _open_at arrives from a
+worker callback and re-points the view at the entry function:
+
+    ('_goto_ea', ['0x3160'])          <- the seek's own navigation
+    ('_open_at', ['0x3160', 'main'])  <- correct
+    ('_open_at', ['0x34d0', 'start']) <- stray, and it wins
+
+The cursor and _cur then sit on 'start' while the trace's pc is elsewhere, and it
+does not settle — measured stable for 3+ seconds. Consequence: a cursor-based
+action taken right after a seek (`>` seeks on the address under the cursor) acts
+on the wrong address.
+
+Not _auto_land: 'start' is not in ENTRY_NAMES, and its guard was set. The
+traceback only shows the Textual callback frame, so the origin is a
+call_from_thread from some worker — most likely a navigation queued earlier
+arriving late, which is the same shape as the stale-result bug fixed in 756589a
+for _open_decomp_entry (that one got a sequence guard; the listing path did not).
+
+To reproduce: seek to an address executed twice, wait for the cursor to reach it,
+then seek again and watch _cur.
+
+Workaround in place: nothing. The M3 tests place the cursor explicitly rather
+than relying on where a seek left it, which is what a user does anyway (you point
+at a line and ask about it) — but the drift is real and worth fixing.