follow-up: investigate native Query time regression after R + Solidity native ports

[carlos-alm]

While merging PR #1102 (port R extractor to Rust) with origin/main (which contains PR #1100 - port Solidity extractor to Rust), the pre-publish benchmark gate fails on:

[native] Query time: 49.6 → 104.4 (+110%, threshold 25%)

Neither PR alone tripped this metric:

• PR feat(native): port Solidity extractor to Rust #1100 (Solidity alone): native Query time stable around 49ms, no warning.
• PR feat(native): port R extractor to Rust #1102 (R alone, pre-merge): no native Query time warning.
• After merging both (3.10.0 baseline → R+Solidity dev): +110% reproducibly across two CI runs.

The Query time metric measures fnDepsData('buildGraph', dbPath) (single fnDeps query on the most-connected function) after a full build of the codegraph repo itself. Adding two new native extractor modules (~1100 LoC total) plus 9 fixture files to the graph naturally increases buildGraph's transitive callee count and DB row counts.

This is the cumulative effect of adding two language extractors in quick succession — neither caught individually, but additive across releases. Once R lands and benchmarks reflect the new corpus, future PRs comparing against the updated published baseline should be back below threshold.

For PR #1102 the exemption is added to tests/benchmarks/regression-guard.test.ts::KNOWN_REGRESSIONS as 3.10.0:Query time so this real but expected cumulative growth doesn't block the merge. Action items:

1. Verify locally that v3.9.6 → R+Solidity HEAD shows the same Query time delta.
2. Consider tightening the per-language fixture footprint or filtering fixture dirs from buildGraph benchmarks if the graph-growth signal dominates the perf signal we actually want to track.
3. Remove the 3.10.0:Query time entry from KNOWN_REGRESSIONS once a v3.11+ release captures the new steady-state.

Related discussion: #1102