A repository's forks page reads its lineage in one batch: `lineage` under 5 ms #6212

The forks page now reads its lineage in two queries instead of one per ancestor and one per fork, and lineage in my test drops from 92 ms to about 3 ms. The fork, following and lineage tests pass (236) and tsc is clean. I did not run the whole suite or the design lint, since no src/web/ file changed.

What changed

• Queries: lineageOf in src/core/following.ts fetches the ancestors in one recursive query and everything below the root in another (listAncestors and listDescendants in src/core/repos.ts). It groups the forks in memory. The viewer's mayRead predicate is applied after the batch, as before, so a private fork stays out of the tree and the "more below" hint. The descendants query reaches one generation past the depth bound so that hint still works.
• Tip reads: most of the time was reading each fork's and its parent's branch tip, plus spawning git for branches that have no commits. The tip reads now run together, each tip is read once per request, and a branch the ref files show is absent no longer spawns git (readTipOrAbsent in src/git/tip.ts). Forks still get their relation within the existing 30-relation budget.
• New test: test/forks-lineage-timing.test.ts builds a lineage four deep with 30 forks and asserts lineage is under 5 ms, as the best of three requests. That is a loose margin. It passed in 7 of 8 runs while I worked, and the miss was before the last tip-read changes.
• Edited test: it also checks the tree shape and that a private fork is not shown to a viewer who cannot read it.
• Edited test: test/forks-ranking.test.ts was racy. It assumed the fork with no commits of its own had already caught up with its parent. The page used to render slowly enough for that to happen. It now waits for that fork to catch up before reading the page. The test was wrong; the code is not.

Left out

• I did not change the "forks" or "drift" phases or the ranking.
• The tree is not cached across requests, because under 5 ms did not need it.

To try it: open /<owner>/<repo>/forks and read lineage;dur in the Server-Timing header, or run bun test test/forks-lineage-timing.test.ts.

Closes #6202

The forks page now reads its lineage in two queries instead of one per ancestor and one per fork, and lineage in my test drops from 92 ms to about 3 ms. The fork, following and lineage tests pass (236) and tsc is clean. I did not run the whole suite or the design lint, since no src/web/ file changed.

What changed

• Queries: lineageOf in src/core/following.ts fetches the ancestors in one recursive query and everything below the root in another (listAncestors and listDescendants in src/core/repos.ts). It groups the forks in memory. The viewer's mayRead predicate is applied after the batch, as before, so a private fork stays out of the tree and the "more below" hint. The descendants query reaches one generation past the depth bound so that hint still works.
• Tip reads: most of the time was reading each fork's and its parent's branch tip, plus spawning git for branches that have no commits. The tip reads now run together, each tip is read once per request, and a branch the ref files show is absent no longer spawns git (readTipOrAbsent in src/git/tip.ts). Forks still get their relation within the existing 30-relation budget.
• New test: test/forks-lineage-timing.test.ts builds a lineage four deep with 30 forks and asserts lineage is under 5 ms, as the best of three requests. That is a loose margin. It passed in 7 of 8 runs while I worked, and the miss was before the last tip-read changes.
• Edited test: it also checks the tree shape and that a private fork is not shown to a viewer who cannot read it.
• Edited test: test/forks-ranking.test.ts was racy. It assumed the fork with no commits of its own had already caught up with its parent. The page used to render slowly enough for that to happen. It now waits for that fork to catch up before reading the page. The test was wrong; the code is not.

Left out

• I did not change the "forks" or "drift" phases or the ranking.
• The tree is not cached across requests, because under 5 ms did not need it.

To try it: open /<owner>/<repo>/forks and read lineage;dur in the Server-Timing header, or run bun test test/forks-lineage-timing.test.ts.

I replaced the timing assertion with query counts and pushed. The lineage and ranking tests pass (10) and tsc is clean. I did not rerun the wider fork suites after these changes.

• Timing test replaced: test/forks-lineage-timing.test.ts no longer asserts any duration. It wraps app.db.query with a counter. lineageOf costs at most 3 queries for the 4-deep, 30-fork tree. The count is identical for a smaller tree rooted at r0, and identical for a leaf fork with no forks of its own. A per-ancestor or per-fork read would break both equalities. I did not run the new test against the old lineageOf, so I haven't seen it fail without the change.
• Unborn branch: the test asserts readTipOrAbsent returns null for a branch that doesn't exist, which is what lets forkRelation skip git. It does not count git spawns directly; it checks the ref-file read that decides whether to spawn.
• Kept: the tree-shape test and the private-fork test.
• Poll loop: test/forks-ranking.test.ts now throws "erin's fork never caught up with its parent" if the fork never syncs, instead of surfacing as a ranking mismatch.
• Formatter: the repo has no formatter config, so I wrapped the long line in src/git/tip.ts by hand.

I dropped the HTTP server and token setup from the timing test, since it no longer fetches the page.