Benchmark large-repo performance and publish the numbers

[jonassaa]

Part of #257 — the benchmark, the numbers and the guard. The marketing-site half
is deliberately held back; see the last section.

"Slow on big repositories" is the most consistent structural complaint about
every established GUI client, and being fast is one of our two strongest claims.
We had no numbers, so it was an adjective.

What landed

• scripts/bench-fixtures.mjs — four fixtures. Three generate from
  git fast-import in seconds, deterministically (seeded content, fixed epoch,
  fixed author), each isolating one dimension: deep (50,000 commits), wide
  (50,000 files, all modified, 5,000 untracked), refs (5,001 branches, 2,000
  tags). The fourth is a real torvalds/linux clone, opt-in.
• src-tauri/benches/repo_bench.rs — drives the real Libgit2Backend
  through the real GitBackend trait. Behind required-features = ["bench"],
  so cargo check and cargo test never build or link it.
• pnpm bench — fixtures → measure → publish, end to end.
• docs/dev/performance.md + docs/dev/benchmark.json — the method,
  what each number does and does not include, and the results.
• test/benchmark.test.ts — re-renders the document's table from the
  published record and fails when they disagree.

Nothing here changes app behaviour, and nothing under site/** is touched,
so merging cannot trigger the site deployment.

What it measures, and what it does not

The backend, not the app: there is no webview in it, so no number includes
React. open_screen narrows that gap by issuing the eleven reads
refreshAll issues, simultaneously — the only shape that can catch "a slow
status blocks everything else on that repo" — and open_screen_ipc adds the
serde_json encoding that happens before the frontend sees a byte.

Every operation a single git invocation can answer carries that invocation as
a baseline, and the ratio is against git's work — its wall clock minus
process start-up (12.4 ms per invocation, measured), because we pay none of it.
That is deliberately the comparison that makes us look worse.

What the first run found

The good. The whole first screen costs 255 ms on a 50,000-commit
repository and 219 ms on one with 7,001 refs. Opening a repository is
0.11 ms. On wide, open_screen (5.42 s) equals status alone (5.42 s) —
eleven concurrent reads cost what the slowest costs, not the sum, which is
git/repo_locks.rs doing its job. A ten-minute soak ran 2,344 fan-outs with
memory flat at 67→69 MB and the median identical in both halves.

The bad. Opening torvalds/linux costs 15.8 s, and ten pages into its
history costs 2 m 38 s. Filed as #473 with the evidence:

• we are at parity with git log --topo-order on the first page — the
  topological sort is the cost, and git pays it too;
• but git pays it once and then skips, while we re-pay it per page (the
  cost is flat in depth);
• collect_ref_map is rebuilt per page too — 16× git's work on the refs
  fixture, with twenty-five times less history than deep;
• and the obvious cheap fix is ruled out: a commit-graph takes git from 9.51 s
  to 21 ms on the kernel and does nothing for us (63.4 s vs 64.2 s),
  because libgit2's revwalk does not read it.

Also filed: #474 — file_history walks to the root of history on any file with
fewer than limit commits, holding the exclusive lock while it does. It is why
the harness picks the most-changed path.

A near miss worth reading

The first draft compared log_page against a plain git log -500 and made the
first page look 14× slower than git. It is not — that baseline was asking an
easier question. The correction is in the spec, and it is why the module doc
insists baselines ask the same question as the thing they measure.

Why the site block is not here

#257's last bullet asks for a measured figure on the marketing site. The block
is written, but it is not shipping in this PR: the honest headline today is
15.8 seconds to open the kernel, and the right response to that number is to fix
it rather than to sell with it. It follows #473.

Keeping the record under docs/dev/ rather than site/src/data/ has a second
benefit worth keeping regardless — site.yml deploys on any push to main
touching site/**, so with the data there a routine pnpm bench would have
redeployed the public website as a side effect.

#257 therefore stays open on that last bullet, which is why this says "Part
of" rather than "Closes".

Verification

• pnpm test — 4,157 tests, 405 files, all passing (includes the new
  guard).
• cargo test — 1,334 passing, 0 failing; cargo test --no-run builds
  zero bench targets, and cargo build --features bench --bench repo_bench
  still builds it.
• tsc --noEmit and tsc -p e2e/tsconfig.json --noEmit — clean.
• The guard was verified against a planted violation, not just observed
  passing: doctoring one figure in the published record fails the re-render
  check, naming pnpm bench as the fix. Restored afterwards.
• The previous revision of this branch went green on all checks including the
  required e2e-linux; this revision only removes the site files and moves the
  record, and re-runs the full JS and Rust suites above.
• No dependency changes — pnpm-lock.yaml and Cargo.lock untouched.

🤖 Generated with Claude Code