app: one instruction map for the decompiled function, not two

Finishing the thing the last commit only worked around. The split view and the
trace path each kept their own per-line instruction map of the same
pseudocode — fetched separately, indexed separately, and keyed differently: the
split one on _cur (the function the CURSOR is in), the trace one on the function
the DECOMPILER has loaded. Those are not the same thing, which is precisely how
the two ended up describing different functions and why I spent a commit
chasing a "sparse decomp_map" that was never sparse.

_apply_split_map now indexes once and both read it. Keyed on the decompiler's
loaded function, and no longer conditional on split being on — the old guard
dropped the result whenever _cur had moved while the fetch was in flight, which
during stepping is almost always.

Measured after: three decomp_map fetches across 28 steps (two for main, one for
the function stepped into), the split map and the trace map are literally the
same object, and both describe what is on screen.

Process note, because this is the second time: my first attempt at this edit
SILENTLY DID NOTHING — the pattern didn't match (a duplicated comment line I'd
mangled), the old method stayed, and the new caller hit its `not self._split`
guard, so the painting tests went from passing to "0 lines". Same failure mode
as the key bindings that never got added. Structural edits now assert that the
anchor was found and that the replacement is present before writing.

212/0 scenarios, 26/0 trace UI, 30/0 project UI, 20/0 split view.

1 files changed, 5 insertions, 4 deletions

diff --git a/TODO b/TODO
index 5d037a7..cb8ad91 100644
--- a/TODO
+++ b/TODO
@@ -109,7 +109,8 @@ waits on the rest. The tempting fallback — nearest mapped address at or before
 the pc — is UNSOUND: C lines are not monotonic in address, and it resolved an
 instruction early in main to a line near the end of the function.
 
-Left alone: _split_ea2line and _split_range are still fed by that guarded path,
-so the split view's own sync can still work from the map of the function you
-just left. It has not caused a visible problem outside stepping, but it is the
-same latent issue.
+FIXED: the split view and the trace path used to keep two parallel maps of the
+same thing, fetched separately and keyed differently — the split one on _cur (the
+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.