Prepare the log walk once and page from it, commit search included

[jonassaa]

Both defects issue 473 measured, in the plain log and in commit search.

What was wrong

log_page built a revwalk for every page. In libgit2 1.9.7 a topologically
sorted walk is not incremental in any sense: git_revwalk_sorting sets
walk->limited, so prepare_walk runs limit_list over the whole reachable
graph and sort_in_topological_order materialises the COMPLETE ordered list
before the first oid comes out. Asking that walk for 500 commits and asking it
for all 1.5 million cost the same thing — so one walk per page paid the
identical price per page, and the cost was flat in depth: page one of
torvalds/linux was 15.95 s and page ten was 157.67 s, ten times one page.
collect_ref_map ran per page beside it.

The measurement the design rests on

Draining a revwalk that has already been prepared is very nearly free,
which is the opposite of what "just cache it" usually costs:

	prepare + take(500)	drain the whole rest of the order
deep (50,000 commits)	560.2 ms	1.9 ms (49,500 more)
torvalds/linux (1,482,923 commits)	31.8 s	63.4 ms (1,482,423 more)

0.2% more buys the entire order. So the walk is prepared once and its output
kept as a Vec<Oid>, and every later page is a slice of it. That is also why
it is a Vec<Oid> and not the prepared Revwalk: holding the walk would mean
holding a git2::Repository alive between IPC calls, outliving the lock
acquisition git/repo_locks.rs orders every access by, to save that 0.2%.

Two invalidation stories, different on purpose. A first page is keyed by
(refspec, start oids), so any ref that moves is a different key and misses. A
continuation is keyed by the frontier it was emitted with and does not consult
refs at all — resuming from a cursor never did, and the set a frontier reaches
is made of commits, which are immutable. The ref map is keyed by a fingerprint
of every ref name and target, so a git tag typed in a terminal invalidates it
exactly like one made in the app.

Commit search reads the same order

log_filtered_page had both defects, and is where they hurt most: a search
matching nothing recent walks a long way before it fills a page, and the next
page threw that walk away.

It deliberately does not go through page_plan. A filtered page visits far
more commits than it returns, so it can run off the end of an order capped at
MAX_ORDER mid-page — and a short page there is indistinguishable, to the user
and to the frontend, from "no more matches exist". cached_filtered_plan asks
WalkOrder::serves with usize::MAX, which admits any offset into a COMPLETE
order and none at all into a capped one; a miss falls back to the
revwalk-per-page the filtered log always had, so a history past the cap is no
worse off than before. It must also not PREPARE a walk to find that out —
that pays for the sort twice on exactly the repositories where it is most
expensive — hence LogCache::has_walk, which asks "has this walk been prepared
before" without counting a hit.

Both sources run one matches closure through a generic filtered_page,
because a search returning different matches depending on whether a walk
happened to be cached is the one bug this must not have.

Tests

Two files, same split, and the split is the point. Transparency drains the
same history (and the same search) once warm and once through a fresh backend
per page, and compares — the pre-change behaviour held against the new one.
Effect asserts on the cache counters, because every transparency test
passes just as well against a cache that never hits.

Six planted violations, each caught by a distinct test; the walk-cache five are
listed in log_walk_cache.rs, and serving every filtered page from its own
walk takes paging_a_search_prepares_one_walk from 1 to 4.

One behaviour is now visible that was always there: when two commits share a
second, which lane comes out first is not promised — libgit2 orders the topo
queue through a git_pqueue with an unstable comparator, so it depends on
insertion order, and a walk restarted from a cursor inserts differently from one
that ran straight through. The walk-per-page version had the same freedom and
used it at every page boundary. The same-second fixture asserts the actual
contract: every commit exactly once, no parent before its child.

Verified on this tree: 1378 Rust tests, 4178 frontend tests across 407 files,
clean tsc, and commit / history-ops / branches / history-diff e2e
green in Docker.

No after-numbers, deliberately

docs/dev/performance.md findings 2 and 3 now say what fixed them, and the
generated results block is untouched — still the "before" it always was.
Two sessions were benchmarking this repository at once and $PGBENCH_HOME is
one shared directory, so control rows moved 25–30% on operations neither change
touches (wide status 5.38 → 3.92 s, diff_commit 1.53 → 1.12 s). That is not
a result, it is two programs sharing a machine. The doc says so, and says to
re-measure on a quiet machine with one session running before publishing an
after.

What this does NOT fix

The first page on torvalds/linux, and so its first screen. That is the
preparation itself, which nothing here makes cheaper — the benchmark already
ruled out the commit-graph, which libgit2's revwalk does not read. That is the
Tier 3 ladder in issue 476. Not closing issue 473 from this PR, because its
title is about exactly that number; the two defects its body measures are both
fixed, so it is worth a look to see whether it should be retitled or closed.

🤖 Generated with Claude Code