Fix: rebuilding the row index on every switch back to the listing

Reported as "decompiler -> listing feels slow", and it was: ~900ms per Tab.

The listing view re-primes every time it is shown, and priming now builds the
whole row index. build_from_index() had no idempotence, so each switch back
re-ran segment_index over the entire segment. Measured on bash, going back to
the listing away from the primed viewport:

  press Tab: 904ms -> 9.7ms, and 5 backend calls -> 0

The index is a pure function of the database and the model is thrown away and
rebuilt whenever anything moves the walk (stale_structure), so a model that is
already indexed can return immediately.

Nothing caught this because the listing was CORRECT the whole time -- only
slow. Every structural assertion passed, boot still measured fast, and the
suite has no notion of "how many calls did that keystroke cost". The new
scenario counts backend calls across three view switches and asserts
segment_index is not among them; with the guard removed again it fails.

Latent and NOT fixed here: materialising a page the viewport reaches for the
first time still happens inside render_line, i.e. an RPC (~20ms) on the UI
loop. That predates this change -- it is how skeleton pages have always
worked -- and is small enough not to read as a stall, but it is the same shape
of bug and wants prefetching onto the worker that already exists for pages.

Full gate: 1064 passed.

1 files changed, 42 insertions, 0 deletions

diff --git a/tests/test_scenarios.py b/tests/test_scenarios.py
index 0bbcf17..c08dc96 100644
--- a/tests/test_scenarios.py
+++ b/tests/test_scenarios.py
@@ -492,6 +492,48 @@ async def s_segment_index(c: Ctx):
             == [(h.ea, h.kind, h.size) for h in streamed._heads])
 
 
+@scenario("reprime_is_free")
+async def s_reprime_is_free(c: Ctx):
+    """Switching back to the listing must not rebuild the row index.
+
+    The listing view re-primes every time it is shown, and priming builds the
+    whole index. Building it is ~600-900ms, so doing it again on each Tab out of
+    the decompiler put nearly a second in front of a keystroke -- the listing
+    was still CORRECT, which is why every other test passed, it was just slow.
+
+    Counting backend calls is the only way to see that, so this counts them.
+    """
+    app = c.app
+    await c.open_biggest("listing")
+    lv = app.query_one(ListingView)
+    if lv.model is None:
+        c.check("listing model exists", False)
+        return
+    await c.wait(lambda: lv.model.complete, 30)
+
+    client = app.program.client
+    original = type(client).invoke
+    seen: list[str] = []
+
+    def counting(self, operation, *a, **kw):
+        seen.append(operation)
+        return original(self, operation, *a, **kw)
+
+    type(client).invoke = counting
+    try:
+        for _ in range(3):                     # decomp and back, three times
+            await c.press("tab")
+            await c.pause(0.05)
+            await c.press("tab")
+            await c.pause(0.05)
+    finally:
+        type(client).invoke = original
+
+    rebuilds = seen.count("segment_index")
+    c.check("switching views never rebuilds the segment index", rebuilds == 0,
+            f"segment_index called {rebuilds}x during 3 view switches: {seen}")
+
+
 @scenario("skeleton_pages")
 async def s_skeleton_pages(c: Ctx):
     """The background grower loads text-less pages; reading one must fill it in.