perf: missing composite SQLite index for references join

[Widthdom]

Summary

references / callers / callees queries join references on (target_symbol_id, source_file_id) and filter by kind, but the schema only has single-column indexes on target_symbol_id. EXPLAIN QUERY PLAN shows SEARCH … USING INDEX … (target_symbol_id=?) followed by a per-row filter for the other columns. Composite indexes that match the actual join shape would let SQLite skip the per-row filter.

Evidence

• The references table indexing is defined at schema creation in src/CodeIndex/Db/DbInitializer.cs (or equivalent migration); look for CREATE INDEX statements on the references table.
• The join shape used by handlers in src/CodeIndex/Mcp/McpToolHandlers.cs (references, callers, callees) consistently combines target_symbol_id with kind and/or source_file_id.

Impact

• references on a high-fan-in symbol (a widely used interface, common enum value) returns rows in time proportional to all references targeting that symbol regardless of kind filter — SQLite walks them and discards the wrong-kind ones at row time.
• For monorepos, the per-row filter cost dominates query latency on the very symbols users most often inspect.

Proposed direction

• Add (target_symbol_id, kind) and (target_symbol_id, source_file_id) composite indexes via a numbered migration.
• Bump PRAGMA user_version.
• Re-run EXPLAIN QUERY PLAN for the three handler paths and verify the new index is picked.

Repro env

• Branch: main @ 2ee912d (release v1.21.0)

[Widthdom]

Work started on branch fix-issue1437.