fix: report unique queries (matches site) instead of log-entry count in CI comment

[veksen]

Summary

The CI comment's "X queries analyzed" disagreed with the query list on the site — most dramatically on the sin-bot PR 12 run, which reported 4236 queries analyzed in the PR comment while the site showed 74.

Root cause: the reported count was computed at ingest time from the number of plan: log entries that passed filtering, not from the number of unique queries we actually analyze. The same 74 distinct queries ran ~57× each across 457 vitest specs, inflating the headline by ~57×.

This change:

• Computes queryStats.analyzed (renamed from queryStats.total) using buildQueries(allResults, config).length — the exact same list used to upload to the site, so the headline always matches what the user sees.
• Drops the separate total counter from the ingest loop.
• Drops the countUploadableQueries / UPLOADABLE_STATES helpers — they duplicated the filter that already lives in buildQueries.
• Restores the Matched N unique queries out of M log entries debug log by using recentQueries.length (no extra counter needed).
• Updates ReportStatistics.total → ReportStatistics.analyzed (docstring: "Number of unique queries analyzed and uploaded to the site"). Consumers updated in the success template and test fixtures.

Why this is the right fix

Before deciding on the dedup approach, we added a diagnostic step to sin-bot's CI workflow that split the log by phase and counted plan: / pg_catalog / information_schema / @qd_introspection lines. Results on the sin-bot run:

Phase	plan: entries	pg_catalog hits	info_schema hits	@qd_introspection
drizzle-kit migrate	41	38	0	0
npm test (457 specs)	4220	95	0	0

Key takeaways that shaped this PR:

1. Migration phase is tiny. 41 plan entries. The initial theory that drizzle-kit introspection was inflating the count does not hold.
2. No information_schema traffic reaches plan: entries in either phase.
3. The 4220 test-phase entries are real application queries, executed by the test suite. 457 specs × ~9 queries each ≈ 4100.
4. The headline mismatch is purely about dedup, not filtering. A pre-count isSystemQuery / information_schema filter would not have materially moved the number.

Given that, delegating to buildQueries is strictly better than any heuristic filter: there is one filter definition (in site-api.ts), and the CI comment is guaranteed to report whatever we actually uploaded.

Test plan

• npx vitest run src/runner.test.ts src/reporters/github/github.test.ts passes (20/20)
• Existing template rendering tests updated for the total → analyzed rename
• New runner.test.ts asserts buildQueries(allResults).length counts exactly the queries reported to the site on a mixed-state input
• Re-run sin-bot PR 12 against this branch and confirm the PR comment reports 74 (or whatever the current analyzed count is) rather than a 4-digit number

Follow-up (not in this PR)

• Consider surfacing the ingest-count elsewhere (e.g. in the Query Doctor run page) if users find the "executions vs. uniques" ratio useful for understanding test-suite shape.
• The diagnostic write-up lives at .context/query-count-handoff.md in this workspace and documents the ruled-out hypotheses so we don't retrace them.

🤖 Generated with Claude Code

[github-actions]

Query Doctor Analysis

View full run details

2 queries analyzed

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,493 (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.}

[ChrisHarris2012]

Consider surfacing the ingest-count elsewhere (e.g. in the Query Doctor run page) if users find the "executions vs. uniques" ratio useful for understanding test-suite shape.

Perhaps the text 2 queries analyzed should be more along the lines of 2 unique query shapes analyzed or something?

[veksen]

Consider surfacing the ingest-count elsewhere (e.g. in the Query Doctor run page) if users find the "executions vs. uniques" ratio useful for understanding test-suite shape.

Perhaps the text 2 queries analyzed should be more along the lines of 2 unique query shapes analyzed or something?

Happy to review the text, created follow-up: #120