Perf: ToolSearch loads only candidate rows from tool_index, not the whole table

[mimeding]

Summary

Why this matters (business)

ToolSearchService is on the agent hot path — it runs every time an agent decides which tools are relevant to a user message. As the user installs more plugins / MCP bundles, the tool_index table grows, and the cost of selecting tools grows with it even though the ranking step (VecturaKit) already narrows the candidate set to a handful.

Today, every tool search reads and decodes every row in tool_index from disk just to filter all-but-a-few-out in Swift. For a workspace with a large tool catalogue this is a measurable per-message tax that scales the wrong way (worse over time as the user adds tools).

What's wrong (technical)

            let toolIds = results.compactMap { reverseIdMap[$0.id.uuidString] }
            guard !toolIds.isEmpty else { return [] }

            let enabledNames = await MainActor.run {
                Set(ToolRegistry.shared.listTools().filter { $0.enabled }.map { $0.name })
            }

            let toolIdSet = Set(toolIds)
            let entries = try ToolDatabase.shared.loadAllEntries()
                .filter { toolIdSet.contains($0.id) && enabledNames.contains($0.name) }

The candidate set in toolIdSet is already small — typically topK (default ~5) plus a fan-out factor. The SQL layer can do an IN (?, ?, ?) lookup in O(candidates × index lookup) instead of returning the entire table for Swift to discard.

Fix

Add ToolDatabase.loadEntries(ids: Set<String>) that issues:

SELECT … FROM tool_index WHERE id IN (?, ?, ?, …)

…with one placeholder per id. SQLite's default SQLITE_MAX_VARIABLE_NUMBER is 999, comfortably above any plausible candidate count.

Update ToolSearchService.search to use loadEntries(ids: toolIdSet) and keep only the enabledNames filter — which depends on MainActor ToolRegistry state and can't be expressed in SQL — applied in Swift.

Same rows in the same order downstream; same ToolSearchResult shape; same scoring. Only the cost of getting there changes.

Tests

Three new cases in ToolDatabaseTests:

• loadEntriesByIdsReturnsOnlyRequested — happy path with three rows, request two.
• loadEntriesByIdsEmptyInputSkipsQuery — empty Set returns [] without issuing invalid SQL like IN ().
• loadEntriesByIdsIgnoresUnknownIds — passing IDs that aren't in the table just drops them.

Changes

• Behavior change (perf only — query result is unchanged)
• UI change
• Refactor / chore (perf)
• Tests (three new ToolDatabaseTests cases)
• Docs

Test Plan

1. cd Packages/OsaurusCore && swift test --filter ToolDatabaseTests should pass.
2. Manually: with a large tool catalogue (e.g. multiple MCP bundles + plugins), trigger several agent tool-aware turns. Compare end-to-end latency before/after. The biggest gain is on cold-cache queries where every row decode shows up in Instruments → SQLite trace.

Checklist

• I have read CONTRIBUTING.md
• I added/updated tests where reasonable
• I updated docs/README as needed (n/a — internal storage helper)
• I verified build on macOS with Xcode 16.4+ (authored in a Linux sandbox; verified each touched file via swiftc -frontend -parse)