Session Search shells out to ripgrep

Umwelten's Session Search scans every Source Session on disk for full-text content matches by spawning the system rg binary rather than building a persistent search index or implementing a pure-JS scanner. Measurements on a representative corpus (1.1 GB / 26,821 Claude Code JSONL files) showed ripgrep completing a literal-string scan in under one second, which removes the only justification for an index: speed. An index would add staleness handling, on-disk format compatibility concerns, and a write path on every session change for a feature whose scanless cold-start is already sub-second. Bundling ripgrep via a Node binding (e.g. @vscode/ripgrep) was rejected to keep the npm package small; a pure-JS scanner was rejected because it would silently get slower as the corpus grew and discard the latency margin that makes the live-editable TUI query practical. The cost is a hard runtime dependency on rg being on the user's $PATH; we accept that and surface a clear install hint on absence. Search v1 covers Claude Code only, because the other adapters (Cursor's SQLite databases, Antigravity's encrypted protobufs) require dedicated parsers rather than line-oriented grep; per-adapter content scanning is a follow-on each adapter can opt into by exposing a scanContent(query) method without changing this decision.