fix: compute list percentiles over the filtered rows (tasks, AI traces, endpoints)

[FrameAutomata]

Closes #313. Rebased onto current main (which now carries 95a65d24), and absorbs what was left of #318 — that PR is closed.

The bug

Three list views computed their percentiles from a second query that carried no filter, while the grouping query that selected the rows applied a search/root filter. The percentile therefore described a different population than the rows the user asked for.

This is worse than a mislabelled column. All three lists sort and paginate on those percentiles — tasks via the needsGoSort path for orderBy=p50_duration|p95_duration|impact, AI traces via orderByMap directly, endpoints via sortEndpointStats and the chart's top-5 ranking. So the page was ordered by the population the user had just filtered out. The count column was already correct, which is exactly why it stayed invisible.

SQLite-only: DuckDB and ClickHouse compute the percentiles inline in the filtered aggregate. So it was also a backend parity break — identical data, different numbers and different row order.

What is fixed here vs already on main

95a65d24 fixed the endpoints case while this work was in review, threading rootFilter into fetchSortedDurations. It did not touch tasks or AI traces.

entity	state
tasks	fixed here — live bug
AI traces	fixed here — live bug
endpoints	fixed on main; this PR adds forward-compat + the missing test

The fix

Each file routes the selecting query and the duration query through one clause builder — taskFilterClause / aiTraceFilterClause / the existing endpointFilterClause — so the two cannot drift apart, and a predicate added there is picked up by both.

The endpoint change carries no behaviour change: with the endpoint pinned by endpoint = :endpoint, the search and method legs cannot alter the row set, so rootFilter is the only load-bearing one. It buys that a future row-level predicate reaches the percentile query automatically. Picking one leg out by hand is how the original split happened, and all three entities now read the same way — which is why it belongs here rather than in a PR of its own.

Also drops a second parameter map in FindGroupedByTaskName: lit's ParseNamedQuery ignores keys the query never references, and the count query consumes params before pagination is added, so one map serves both.

Verification

Four regression tests. The three that cover a live bug fail on the pre-fix code with exactly these values:

--- FAIL: TestTaskRepository_FindGroupedByTaskName_PercentilesUseFilteredRows
    P50 computed over unfiltered rows: got 5.05s, want 100ms
    P95 computed over unfiltered rows: got 10s, want 100ms
--- FAIL: TestTaskRepository_FindGroupedByTaskName_RanksOnFilteredRows
    page ordered on unfiltered percentiles: got "task.fast-root" first, want "task.slow-root"
--- FAIL: TestAiTraceRepository_FindGroupedByTraceName_PercentilesUseFilteredRows
    P50 computed over unfiltered rows: got 15.1s, want 200ms
--- FAIL: TestAiTraceRepository_FindGroupedByTraceName_RanksOnFilteredRows
    page ordered on unfiltered percentiles: got "trace.fast-root" first, want "trace.slow-root"

The fifth — TestEndpointRepository_GetEndpointStackedChart_RanksOnFilteredRows — passes on main. 95a65d24 fixed that path but only tested the grouped list, so this guards the existing fix rather than reporting a live bug. Stating that so a green run is not mistaken for "reproduced and fixed."

All tests live in the untagged telemetry package, so they run against all three backends and pass on DuckDB and ClickHouse unchanged — that contrast is the parity assertion.

Also reproduced end-to-end, not just in tests. Two binaries on the same seeded SQLite database, populated over real OTLP ingest (root and non-root CONSUMER spans for tasks, gen_ai.* spans for AI traces), queried over HTTP:

	main	this branch
tasks, rootFilter=all	count=8 p50=5050ms p95=10000ms	same
tasks, rootFilter=root	count=4 p50=5050ms p95=10000ms ❌	count=4 p50=100ms p95=100ms ✅
ai-traces, rootFilter=root	count=4 p50=15100ms p95=30000ms ❌	count=4 p50=200ms p95=200ms ✅

Local: go test -race -count=1 ./app/..., the DuckDB-tagged suites, go vet ./app/..., gofmt — all clean.

Follow-ups, not in scope

• idx_endpoints_project_endpoint is (project_id, endpoint) with no recorded_at, so per-group duration queries scan a group's whole retained history to answer a short window.
• The structural fix: SQLite splits the percentile query only because it has no percentile aggregate. One filtered query ordered by (group, duration) partitioned in Go — the shape getStackedChartWithPercentiles already uses — removes the drift and the per-group N+1. The tests here protect that refactor.

🤖 Generated with Claude Code