Search assistant replies and checkpoint bodies via the FTS5 index

[jongio]

Searching the session list for a bug or PR number returned nothing when that number only appeared in Copilot's reply rather than in what the user typed.

What was wrong

The session store ships an FTS5 search_index table covering full turn text and every checkpoint field, but the list filter never touched it. Deep search built a LIKE predicate over turns.user_message, checkpoint title and overview, file paths, and refs. Assistant replies, checkpoint history, work done, technical details, and next steps were all unreachable.

SearchSessionsFTS did use the index, but only the Copilot SDK search tool ever called it.

The change

Deep search now also matches s.id IN (SELECT session_id FROM search_index WHERE content MATCH ?) when the index is present.

The index clause is additive rather than a replacement. FTS5 tokenizes, so it misses substrings inside a token: searching 1137 finds bug 1137 but not PR1137, which LIKE catches. Keeping both makes the result set a strict superset of the old behavior.

Stores without the index get an assistant_response LIKE clause instead, so assistant text is searchable there too.

Query terms are wrapped in double quotes before being passed to MATCH, so FTS5 operators (-, *, NEAR, ^) are treated as literals and can't turn a search into a syntax error that breaks the whole list. A whitespace-only query skips the MATCH clause rather than issuing an empty phrase.

Verification

Against a real 20k-session store, searching 1137:

	sessions found
before	6
after	13

The recent session that prompted the report (the number appeared only in an assistant reply) is now in the results.

Tests

• assistant-only match through the index
• checkpoint body match (history, technical details, files)
• no-match, so the index clause can't match everything
• FTS5 operator characters as the whole query
• grouped list path uses the same predicate
• filter-builder shape for both the indexed and fallback branches