trace: paint the execution trail — including on the decompiler

Both code views now show where you came from and where you're going: the
instruction you're on ('now'), the ~96 steps behind it ('past', warm) and the
~96 ahead ('future', cool).

A trail, not all of history. Painting every address the trace ever touched says
almost nothing on a loop-heavy program; the last and next few dozen steps say
how you GOT here. Where an address appears on both sides — a loop body, which is
most of them — the nearer side wins, because that's the one explaining the step
you just took or are about to.

**The pseudocode is painted too**, which is the reason to build this here rather
than use Tenet. A trace records instructions, so that's what Tenet paints. We
already have decomp_map from the split-view work, saying which instructions each
C line covers, so the same trail lands on the decompilation:

    line  46 now    | v3 = getenv("POSIXLY_CORRECT");
    line  47 future | v4 = (__int64)*a2;
    line  49 future | if ( v3 )

A C line covers many instructions, so it takes the strongest kind present: now
beats past beats future — if the instruction you're standing on belongs to this
line, this line is where you are.

Two things kept cheap: the trail is recomputed per SEEK rather than per repaint
(~200 lookups, and repaints vastly outnumber steps), and decomp_map is cached
per function because it's an RPC and stepping is interactive.

The colours sit deliberately under the code palette — the trail says "you came
through here", the text still has to read as code.

tests: +8 UI (21) — the listing carries now/past/future and it reaches the
screen; pseudocode is painted; exactly ONE C line is 'now' and it is the line
covering the current instruction (not merely some executed line, which is the
mistake this check exists to catch). 209/0 scenarios, 27/0 model, 10/0 diff.

1 files changed, 5 insertions, 0 deletions

diff --git a/README.md b/README.md
index 42370bc..2d400e5 100644
--- a/README.md
+++ b/README.md
@@ -126,6 +126,11 @@ ones the current instruction wrote are highlighted) and a timeline. `]` and `[`
 step one instruction forward and back; `}` and `{` step over a call by following
 the stack pointer. The code view follows.
 
+Both code views are painted with the execution trail: where you just came from,
+where you're about to go, and the instruction you're standing on. The pseudocode
+view is painted too — a trace records instructions, but `decomp_map` says which
+instructions each C line covers, so the same trail lands on the decompilation.
+
 Trace addresses are rebased onto the database automatically — a traced process
 is relocated, so nothing lines up until that's solved.