fix(embedding): enable RAG with the built-in local model and batch local embeddings

[mrsibe]

What does this PR do?

Two fixes on the embedding path, both found from the same log line:

1. RAG now runs with the built-in local model. chatHandlers decided whether to retrieve at all from ConnectionManager.getEmbeddingClient(), which only returns a client for a remote embedding connection. Local is the default, so RAG was skipped on every message.
2. Local embeddings are batched. The remote path split work into batches; the local path sent the whole array through one ONNX forward pass.

It also stops logging the local fallback as a warning, and makes the import and test-loader changes needed to test any of this.

Why?

The RAG gate (the "chat does not retrieve" blocker)

const embeddingClient = await connectionManager.getEmbeddingClient()
if (embeddingClient) { /* retrieve + inject context */ }
else { Logger.debug('ChatHandlers', 'RAG disabled: No embedding model configured') }

getEmbeddingClient() is remote-only. With the built-in local model (the default) it is always null, so retrieval stayed none, no system context was injected, and no sources/citations were recorded — while the notebook was indexed correctly. EmbeddingService.resolveBackend() already falls back to the local backend; the search was never the problem, the gate was.

The same call produced [ConnectionManager] No embedding model configured on every index and query for local users. That is the normal fallback path, not an error.

Local batching (the "import hangs" blocker)

EmbeddingService.embedBatch() handled remote in batches of 20 but handed the local path the entire array in one call, which LocalEmbeddingBackend tokenizes and runs as a single forward pass. For the 694-chunk book in #133 that is one ~694 x 512 input: unbounded memory peak, a long synchronous tokenization, and onProgress firing once at the very end, so the UI progress sat at its start value.

Fixes #132. Fixes #133. Related to #125, #82.

What changed?

• chatHandlers.ts: gate on knowledgeService.isEmbeddingAvailable() (remote configured or local model installed) instead of the remote-only client.
• KnowledgeService.ts: add isEmbeddingAvailable(), delegating to EmbeddingService.isAvailable().
• ConnectionManager.ts: the missing-remote-connection case is now a debug line that names the local fallback.
• EmbeddingService.ts: new localBatchSize (default 16), embedLocalInBatches() — per-batch onProgress and an event-loop yield between batches. The ConnectionManager import becomes type-only (it was only used as a type and dragged electron/config into node --test).
• test/ts-resolve.mjs: also resolve directory imports to index.ts, the other shape the sources use (../../shared/types).

How was this tested?

• npm test — 281 pass, 0 fail (5 new).
  • test/embeddingBatching.test.ts: a fake pipeline records batch sizes — [16, 16, 8] for 40 texts with localBatchSize: 16, [16, 16, 1] for the default, per-batch progress [16,40] -> [32,40] -> [40,40], and the single-embed path.
  • test/chatRagGate.test.ts: fails if the gate goes back to connectionManager.getEmbeddingClient(). Verified by temporarily restoring that call.
• npm run typecheck, npm run build — pass.
• npm run build:unpack and smoke:packaged — 21/21 checks pass (run headless with an isolated --user-data-dir; CI uses xvfb-run).

Not verified: a real 694-chunk document end to end against the actual local model. The new tests pin the batching contract with a fake pipeline; the book-sized run is the acceptance criterion in #133, and the retrieval: 'used' path for a local-only profile is the acceptance criterion in #132.

Screenshots / recordings

Not applicable.

Checklist

• I have reviewed my own changes.
• npm run typecheck passes.
• npm run build passes.
• I have tested the affected user workflow.
• I have not included unrelated changes.
• I have updated documentation when necessary.

Desktop / build changes

• npm run build:unpack passes.
• npm run smoke:packaged passes.