fix(embedding): skip warmup for remote providers

[gabrielrinaldi]

Summary

• skip local embedding warmup when embeddingApiUrl and embeddingApiKey are configured
• avoid loading the local @xenova/transformers stack for remote embedding setups
• preserve existing behavior for local embedding models

Why

OpenCode installs plugins with bun add --ignore-scripts, which can leave native transitive dependencies unresolved in some environments. For opencode-mem, remote embedding mode does not need local transformer warmup, so eagerly warming that path can fail unnecessarily during plugin startup.

This change keeps remote embedding mode on the remote path from the start, which avoids startup failures while leaving local embedding behavior unchanged.

[Copilot]

Pull request overview

This PR adjusts embedding initialization so that when an external (OpenAI-compatible) embeddings API is configured, the service skips local model warmup and avoids loading the @xenova/transformers stack, preventing unnecessary startup failures in remote-embedding setups.

Changes:

• Short-circuit EmbeddingService.warmup() when embeddingApiUrl and embeddingApiKey are set (remote mode).
• Update bun.lock metadata (configVersion).

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
src/services/embedding.ts	Skips local embedding warmup for remote providers to avoid loading local transformer dependencies unnecessarily.
bun.lock	Lockfile metadata update (configVersion).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[NaNomicon]

Thanks for digging into this. From tracing the current code, I think the remote warmup short-circuit may already exist today.

warmup() delegates to initializeModel(), and initializeModel() already returns early before loading @xenova/transformers when both embeddingApiUrl and embeddingApiKey are set. So I’m not yet seeing the failing path this PR changes, aside from warmup() no longer setting initPromise in the remote case.

Could you share the concrete repro or stack trace this fixes, or add a regression test showing current startup still reaches the local transformer path in remote mode? If there is an existing bug here, I think we should target that path directly rather than duplicate the remote-mode check.

[gabrielrinaldi]

I think #90 is a more elegant solutions, closing this