getDominantFile returns null when test or generated files fill its 20-row window #2578

Summary

computeDominantFile takes the top 20 files by in-file edge count in SQL (LIMIT 20), and only then drops test and generated files in code. When 20 or more low-value files outrank the real code, nothing is left and it returns null, even though a clear dominant file exists. With fewer than 20 such files, nextEdgeCount can be understated, because the runner-up was cut off by the limit. That affects the edgeCount >= 3 * nextEdgeCount check that decides the directory boost.

Reproduction (verified)

On main at c71a3d0, built from source, Linux (WSL2), Node 22.22.2.

• src/core.ts has a chain of 60 functions, each calling the next (60 in-file edges), and src/second.ts has a chain of 50.
• 20 files tests/tN.test.ts each have a chain of 70.

const cg = await CodeGraph.init(dir, { index: true });
(cg as any).queries.getDominantFile(); // → null

Expected: { filePath: 'src/core.ts', edgeCount: 60, nextEdgeCount: 50 }.

Generated code makes this plausible in real repos. Android R.java per module, protobuf *OuterClass.java / *Grpc.java, and test-heavy monorepos could fill the window.

Same pattern (inferred, not reproduced)

getTopRouteFile takes the 20 files with the most routes, then filters. Both totalRoutes and the 30% share check are computed on the truncated, filtered set.

Possible fix

Push the test-path exclusion into SQL, or keep fetching past 20 rows until 20 rows survive the filter (or the rows run out). The generated-file check needs the files table, so the second option may be simpler.

Related

#2575 (the plan fix for the same query, #2571), and #2349 / #2115, which cache the result. None of them changes the window.