Skeleton pages: stop rendering 227k rows to count them (3x boot)

ListingView._grow streams the entire segment in the background for one
reason: to learn how many rows it has, so the scrollbar and paging are
right. It did that by rendering every row in full -- 227,500 rows of a
1.2MB bash, 911 backend calls, 9.3 seconds -- essentially none of which is
ever looked at.

generate_disasm_line is 22x the cost of the walk around it, so heads() gains
text=False: a SKELETON page with the same rows at the same addresses with the
same kinds and sizes, and no rendered text. Measured identical structurally
(rows, addresses, kinds, sizes and cursor all match a real page) which is
what makes one swappable for the other later. It also skips the digest
(nothing to go stale) and lets the client skip the bulk opcode read, so a
page costs ONE round trip instead of two.

Client side is deliberately tiny, because the machinery already existed: a
skeleton page is just a page whose text is stale. It is marked with a
sentinel generation no _text_gen can equal, and the FIRST read of it goes
through the same _ensure_text/_ensure_page path a rename uses -- which
already refetches a page by address, verifies the structure still lines up
and splices it in. Two staleness gates learn to fire for _skeleton as well
as _renamed; that is the whole integration.

bash boot: 911 calls / 9.26s -> 456 calls / 3.12s, 3.0x. The trade is that a
page you actually display is fetched twice (3.3ms + 9.4ms vs 9.4ms), paid
only for what is shown. _prime still loads real pages, so the viewport you
land on is never a skeleton.

The failure mode is BLANK ROWS, not an exception, and nothing in the suite
scrolled far enough to see one: _prime renders the first ~1000 rows for real,
so a test that pages down a few screens passes against a completely broken
implementation. The new scenario reads deep rows through both the model and
the render path, and asserts materialising changes neither the row count nor
the walk. Verified by reverting the two gates: it fails with text=''.

Full gate: 1050 passed.

1 files changed, 12 insertions, 2 deletions

diff --git a/idatui/app.py b/idatui/app.py
index e193c65..a806d65 100644
--- a/idatui/app.py
+++ b/idatui/app.py
@@ -1262,13 +1262,23 @@ class ListingView(SearchMixin, NavMixin, ColumnCursor, ScrollView, can_focus=Tru
     @work(thread=True, exclusive=True, group="listing-grow")
     def _grow(self) -> None:
         """Stream the rest of the segment's heads in the background, growing the
-        virtual size as they land so the scrollbar/paging catch up."""
+        virtual size as they land so the scrollbar/paging catch up.
+
+        SKELETON pages: this loop only exists to find out how many rows the
+        segment has, and it used to render every one of them to do it -- 227k
+        rows for a 1.2MB bash, ~9s, essentially all never displayed. A skeleton
+        page has the same rows at the same addresses and no text, is 2.8x
+        cheaper and costs one round trip instead of two. The first read of one
+        materialises it through the same path a rename uses, so only what is
+        actually shown ever gets rendered. _prime (the viewport) still loads
+        real pages, so what you are looking at is never a skeleton.
+        """
         model = self.model
         if model is None:
             return
         since = 0
         while not model.complete:
-            if model.load_next_page() == 0:
+            if model.load_next_page(text=False) == 0:
                 break
             if self.model is not model:  # a new load() replaced us
                 return