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

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.

0 files changed, 0 insertions, 0 deletions