fix: stop reporting an AI-trace stats failure as 0ms latency

[FrameAutomata]

Found while reviewing #319. Pre-existing, unrelated to that PR's percentile work, so it's here on its own.

The bug

GetTraceNameStats on the SQLite telemetry backend swallowed the error from its percentile query:

durationRows, err := lit.SelectNamed[aiTraceDurationRow](db.TelemetryDB, ...)
if err != nil {
    return stats, nil   // <- error discarded, stats partially filled
}

On any failure — context deadline on a large trace_name, a locked telemetry DB, a scan type error — the caller got a struct with a real Count, AvgDuration and token totals sitting next to MedianDuration and P95Duration of exactly zero. Nothing logged, no CaptureException.

Zero is a plausible latency. An operator reads "median 0ms, p95 0ms" as a fast trace, not a failed read.

It's also a backend divergence. DuckDB (duckdb/ai_trace.repository.go:386) and ClickHouse compute the percentiles inside the aggregate query and propagate the error with return nil, err. The SQLite endpoint and task equivalents already return nil, err too. This was the single path that fabricated a value.

The fix

return nil, err.

Worth noting what this does not do: the route already treats stats as best-effort — it nils them and still answers 200 with the trace list — so propagating the error is not a new 500 path. It swaps a misleading zero for an absent stats block. The caller's discard now goes through traceway.CaptureException per CLAUDE.md's non-stopping-error convention instead of vanishing.

Trade-off

On failure the caller now loses the fields that did read successfully (count, avg, tokens, cost) rather than getting them alongside fake zeros. That's deliberate — those values are already visible in the trace list rows the same response carries, and a partially-true stats header is worse than none.

No regression test, and why

Both queries in the function read ai_traces, so there is no way to fail only the percentile read from a test without injecting a fake executor — the repositories take db.TelemetryDB directly and have no seam for it. Dropping the table fails the first aggregate query too, which already returned nil, err before this change, so such a test would pass identically pre- and post-fix and assert nothing. Flagging that plainly rather than shipping a test that looks like coverage.

Verification

go build ./..., go vet ./app/..., go test -race -count=1 ./app/..., and the DuckDB-tagged repository suite all pass. gofmt clean.

🤖 Generated with Claude Code