feat: model CI queries at the repo's configured statistics scale

[veksen]

Implements Query-Doctor/Site#3119, the last child of the predict-at-scale epic (Query-Doctor/Site#3114). The Site side is on feat-predict-at-scale (Query-Doctor/Site#3698).

Goal

Query Doctor's homepage promises performance predicted at 10× and 1000× the data. Everything for that now exists except the step that reads the setting: the Site stores a per-repo statistics scale, the app labels a run with it, the API refuses to compare runs across a scale change, and core multiplies row counts by it. This PR is the analyzer reading the setting and using it.

What

Before: a repo could set a statistics scale in CI settings and nothing happened. Every run was planned against the current data.

After: a repo set to 10× has its CI queries planned against ten times the table and index sizes, so an index that only starts mattering at that size shows up before the table gets there. The run log says Modeling queries at 10x the current data size. A repo left at 1× posts exactly the payload it posted before.

How

Read src/config.ts first. configuredStatisticsScale is the one place that reads the setting off the relay's repo config. The read is defensive because core's RepoConfig type does not declare statisticsScale even though the Site has sent it since Site#3115: a missing, non-numeric, or sub-1 value means the current size, so an analyzer talking to an older Site keeps working and a nonsense value never reaches the planner. The cast can go once core ships the field.

Runner.determineStatsMode takes the scale and applies it to whichever mode wins its existing precedence: production stats, then a stats file, then the synthetic assumption. It is applied in one place, atScale, rather than three times inside the branches. A scale of 1 is left off the mode entirely, which keeps the posted payload byte-identical for repos that never touch the setting.

Nothing else changes shape. The scale rides inside the statisticsMode the reporter already posts, and the Site stamps it on the run (Site#3694). CiQueryOptimization.cost stays a single number.

@query-doctor/core moves to ^0.18.0, the first published version whose StatisticsMode carries scale.

Tests

src/config.test.ts: the scale is read from a repo config, a config without one means 1×, and a 0 or a "10" is ignored.

src/runner.test.ts: production stats are modeled at the configured scale, so is the synthetic assumption, and 1× or no scale leaves the mode unscaled. Written before the change; the first two failed with expected undefined to be 10.

npm run test: 374 passed across 38 files. npm run typecheck: clean.

Verifying end to end

Not done here, and worth doing on a real repo once the Site branch merges: set a repo to 10×, push, and check the run header reads modeled at 10× and the costs move. The Site side refuses to compare that first run against its 1× baseline, which is the intended re-baseline (Site#3118).

[github-actions]

Query Doctor Analysis

3 queries analyzed

0 regressed · 0 improved · 0 new · 0 removed

2 pre-existing issues

• SELECT "guests"."id", "guests"."session_id", "guests"."username", "guests"."avatar_path", "guests"."color", "guests"."side", "guests"."audio_recording_path", "guests"."audio_recording_public", "gue...
  index assets(event_id, inserted_at desc)
  cost 31,003,449 → 1,498 (100% reduction)
• SELECT * FROM guest_ip_addresses WHERE ip_address = '127.0.0.1';
  index guest_ip_addresses(ip_address)
  cost 154,402 → 8 (100% reduction)

_{Using assumed statistics (10000000 rows/table). For better results, sync production stats.}

_{More detail → get_ci_run({ runId: "019faaf6-f15b-7236-a55a-c049ce7300cb" }) · view run · docs}