fix: Sidebar session search ranks every matching message before applying the 20-50 result limit

[sam-saffron-jarvis]

What changed

• Bound session FTS search to a materialized, rank-ordered candidate set before running the per-session ROW_NUMBER() de-dupe.
• Apply archived/category/compaction-tail filters before the candidate cap so candidates are useful, then keep the existing final one-result-per-session ordering and output limit.
• Added coverage for broad common-term search across many long sessions plus a benchmark for the web/sidebar-shaped common-term case.

Why this is high-value

Sidebar and term-llm sessions search queries cap returned sessions to small limits, but the old SQL still fed every messages_fts MATCH row into the window function. Common searches such as "error", "fix", or "the" could therefore rank/window a large fraction of the transcript database and monopolize the store's single SQLite connection. The new raw match CTE uses ORDER BY messages_fts.rank LIMIT <limit-derived candidate cap>, so SQLite only hands the rank/window stages a bounded candidate set (for the normal 20-50 result path, roughly 10k-25k candidates instead of all matching messages).

Validation

• go test ./internal/session
• go test ./internal/session -run '^$' -bench BenchmarkSQLiteStoreSearchCommonTermWithLargeHistories -benchmem -count=1
  • BenchmarkSQLiteStoreSearchCommonTermWithLargeHistories-32 16 65184496 ns/op 48889 B/op 965 allocs/op
• go build ./...
• go test ./...
• git diff --check