A repository's forks page lists the forks with the most work to offer first: commits ahead, then fewest behind #5970

The forks page now lists a repository's direct forks with the most work to offer first. The new test and the related suites (forks, following, forks-timing, parity) pass, and tsc and the design lint are clean. I did not run the whole bun test.

• Order: forks sort by commits ahead (most first), then fewest behind, then the newest tip commit date. Forks with nothing ahead come last under N forks with nothing new. A fork whose standing can't be read counts as having nothing new.
• Rows: each row says N ahead · M behind and when the fork last moved. A fork that is ahead gets a Compare link to its /pulls/new page, where the work can be proposed upstream. The repo has no separate compare route, so I used that page.
• How it's built: the sort is a pure function, rankForks, in src/actions/forks.ts, with driftOfForks reading each fork's drift and tip date from git. It is capped at 60 forks per page view (one git call each), and the forks past 60 are left out of the ranking with no note on the page. The page is in src/web/pages/repo.ts.
• Kept: the existing family tree stays below the ranking under "The family". It also shows deeper forks and the "you are here" marking.
• Tests: test/forks-ranking.test.ts checks the sort rule directly, including the tie-breaks. It also seeds four forks (3, 2 and 1 ahead, and one level) and checks their order, the words, the Compare links and the "1 fork with nothing new" heading.
• Existing tests changed: both assertions went stale because the page changed, and neither was wrong about behaviour.

- test/forks-timing.test.ts now expects a drift phase between lineage and render. - test/following.test.ts now looks for the nested fork after "The family", because a fork also appears earlier in the ranked list.

• Left out: nothing in src/http/mcp.ts, src/contract/openapi.ts or docs/DESIGN.md was touched, so the ranking has no MCP or API form yet.

To try it, open /:owner/:name/forks on a repository that has forks.

Closes #5960

The forks page now lists a repository's direct forks with the most work to offer first. The new test and the related suites (forks, following, forks-timing, parity) pass, and tsc and the design lint are clean. I did not run the whole bun test.

• Order: forks sort by commits ahead (most first), then fewest behind, then the newest tip commit date. Forks with nothing ahead come last under N forks with nothing new. A fork whose standing can't be read counts as having nothing new.
• Rows: each row says N ahead · M behind and when the fork last moved. A fork that is ahead gets a Compare link to its /pulls/new page, where the work can be proposed upstream. The repo has no separate compare route, so I used that page.
• How it's built: the sort is a pure function, rankForks, in src/actions/forks.ts, with driftOfForks reading each fork's drift and tip date from git. It is capped at 60 forks per page view (one git call each), and the forks past 60 are left out of the ranking with no note on the page. The page is in src/web/pages/repo.ts.
• Kept: the existing family tree stays below the ranking under "The family". It also shows deeper forks and the "you are here" marking.
• Tests: test/forks-ranking.test.ts checks the sort rule directly, including the tie-breaks. It also seeds four forks (3, 2 and 1 ahead, and one level) and checks their order, the words, the Compare links and the "1 fork with nothing new" heading.
• Existing tests changed: both assertions went stale because the page changed, and neither was wrong about behaviour.

- test/forks-timing.test.ts now expects a drift phase between lineage and render. - test/following.test.ts now looks for the nested fork after "The family", because a fork also appears earlier in the ranked list.

• Left out: nothing in src/http/mcp.ts, src/contract/openapi.ts or docs/DESIGN.md was touched, so the ranking has no MCP or API form yet.

To try it, open /:owner/:name/forks on a repository that has forks.

The forks ranking now works in the terminal as well as on the page, and all four of juniper's points are addressed. I ran the forks, following, forks-timing, parity, TUI and new ranking tests and tsc; all pass and the design lint is clean. I did not run the full bun test.

• Terminal. src/tty.ts doesn't exist. The terminal is src/tui/, and it had no forks view, so I added one. f in a repository opens src/tui/screens/forks.ts, which uses the same ranking and the same words as the page (actions/forks.ts). A new test opens that screen and checks the order, 3 ahead · 1 behind and 1 fork with nothing new.
• README. A new "Ranked forks" section says how to read the ranking.
• 60-fork cap. The page and the terminal screen now say Ranking the first 60 of N forks when forks are left out. A test checks this with 61 forks.
• Compare. The new-pull page for a fork defaults to proposing to the parent, not the fork itself. A test now asserts the baseRepo=parent field and that the page names alice/app. The Compare link is now the standard button (btn), so no new class is needed. It also removes an invalid anchor nested inside the row link; the row is now a plain row with the fork name as its link.
• Git cost. Each fork now costs one git log that returns the tip and its date together. The rev-list standing is cached by the pair of parent and fork tips, bounded at 2,000 entries, so a view where nothing moved is one call per fork instead of two. I did not measure the time against the 50 ms budget. A test checks that a repeated view returns the same standings.

enter on the terminal forks screen now opens the selected fork's workspace, so the hint is true. The forks, following, forks-timing and new ranking tests pass (35) and tsc is clean. I did not run the full bun test.

• Enter: the screen keeps the repo for each ranked row and enter pushes that fork's workspace (src/tui/screens/forks.ts). A new test in test/forks-ranking.test.ts presses enter on the top fork. It checks that the forks screen is gone and the workspace for dan/app is showing.
• Duplicate listing: I did not drop the direct forks from the family tree. The tree's job is "who follows whom", and the "you are here" marking only makes sense with the whole tree. I relabelled the heading to "The family, by who follows whom" so it no longer reads as a second copy of the ranking.
• Preview: I haven't seeded forks on the preview. I can't create them from here; the seeded-fork coverage is in test/forks-ranking.test.ts.