Cap the file-history walk, share the lock, and let it be cancelled

[jonassaa]

Closes #474.

file_history walks from HEAD keeping commits whose tree differs from their
parent's at the path, and stopped at limit matches. A file with fewer
changes than the limit has nothing to stop on, so the walk ran to the root of
history with a tree comparison at every commit — and it held the exclusive
repository lock for all of it.

Measured on the linux benchmark fixture (warm, one click on a path with fewer
than 200 changes):

walk	cost
uncapped — 1,482,923 commits, every one compared	135.6 s
capped at 50,000 visits (this PR's default)	18.3 s
…of which: libgit2's own revwalk preparation	14.5 s
…of which: 50,000 commits of tree comparison	4.1 s

What changed

A visit cap beside the match cap. The result now carries visited and
stoppedAt (Exhausted / MatchLimit / VisitLimit), because the three
outcomes look identical on screen — a list that ends — and mean completely
different things. The screen says which one happened, with the number that was
actually searched, and offers Search all of history: the old unbounded walk,
asked for deliberately, the way the blob ceiling's "diff it anyway" works.

with_repo_read. This is the longest read in the backend, and holding the
exclusive lock for it queued every other operation on the repository behind a
walk that could take minutes — the failure #400 set out to remove, surviving in
the op least able to afford it. The proof it writes nothing is in
docs/dev/backend.md; notably it never reads the index, so there is no
accidental refresh for anything else to have come to depend on (the status
regression next door is the cautionary tale).

Cancellable, because 18 s is still a wait worth stopping. A new
cancel::Scope::Walk — the first scope with nothing to signal, so the command
hands the backend a predicate to poll between commits and the backend knows
nothing about cancellation. The screen also cancels on the way out, so leaving
does not leave a walk running.

A bug this surfaced on the way: the command palette's Cancel row was gated
on "is this cancellable" but hardcoded to the network mechanism, so it would
have offered a Cancel for a history search and reached nothing. "Can it be
cancelled" and "what cancels it" are one table now, with one store action both
surfaces call.

The optimisation this deliberately does not make

Dropping Sort::TOPOLOGICAL looks like the fix and buys nothing. libgit2's
sorted revwalk pre-walks the whole graph before yielding anything — 14.2 s to
the first oid, 14.7 s for all 1.48 million, measured within 1% for TIME
and TIME | TOPOLOGICAL alike. Sort::NONE is incremental and unusable here:
it yields commits in traversal order, so the first 50,000 are not the newest
50,000 and a capped walk could miss last week's change while reporting one from
2011. The cap has to mean "the newest N commits" or it cannot be said out loud.

That fixed floor is very probably the one behind log_page's first page too,
which is worth knowing before anyone optimises the log by changing its sort. It
is written up in docs/dev/performance.md beside the commit-graph measurement
that rules out the other cheap fix.

Verification

All on the final tree.

• cargo test — 96 test binaries, no failures. The visit cap, the two ceilings
  reported separately, the exactly-on-the-boundary case that would otherwise
  make the notice lie about every ordinary repository, cancellation (including
  that it stops rather than running on and discarding the answer), and a
  rendezvous test that the walk does not exclude another read — the
  predicate is called with the lock held, so it is a place to stand still and
  check whether a concurrent status can get in. Verified by planting
  with_repo back: that test fails on its bounded wait and only that one.
• pnpm test — 407 files, 4,178 tests, all passing.
• pnpm tsc --noEmit and pnpm exec tsc -p e2e/tsconfig.json --noEmit clean.
• pnpm test:e2e:docker — snapshot rebuilt, then file-history (4 passing),
  cancel (2) and palette (8), 0 stalled driver scripts. Two of the
  file-history cases ask the commands directly: nothing on screen distinguishes
  a readable stoppedAt from an unreadable stopped_at, and the frontend
  deliberately swallows a cancel_walk rejection, so both would fail silently.
• Two frontend plants confirmed the new tests bite: removing the cancel-ordering
  chain fails the ordering test, and the notice tests fail on a hardcoded cap.

🤖 Generated with Claude Code