feat: add Jina as embedding provider for code indexing

[Onnson]

Summary

This PR adds Jina AI as a new embedding provider option for the code indexing feature in Roo Code.

Changes

• Added Jina to the EmbedderProvider type across the codebase
• Implemented JinaEmbedder class with full support for:
  • Multi-vector embeddings using jina-embeddings-v4 model
  • code.query downstream task for code-specific embeddings
  • Proper batching and rate limiting
  • Error handling and validation
• Updated UI components to allow selecting Jina as provider and entering API key
• Added localization support for Jina-related messages
• Updated type definitions and schemas

Implementation Details

• Uses Jina's REST API endpoint at https://api.jina.ai/v1/embeddings
• Supports models: jina-embeddings-v4, jina-embeddings-v3, and jina-clip-v2
• Configured with appropriate dimensions and score thresholds for each model
• Follows the same pattern as other embedding providers for consistency

Testing

• Successfully built and packaged the extension
• Installed and tested in Windsurf Next
• All TypeScript type checks pass
• All linting checks pass

Usage

1. Select "Jina" as the embedding provider in code indexing settings
2. Enter your Jina API key
3. Choose the model (defaults to jina-embeddings-v4)
4. The embedder will automatically use code.query as the downstream task

This allows users to leverage Jina's powerful code understanding capabilities for better code search and indexing.

---

Important

Add Jina as an embedding provider for code indexing, including configuration, UI updates, and validation support.

• Behavior:
  • Add Jina as an embedding provider in EmbedderProvider type.
  • Implement JinaEmbedder class for multi-vector embeddings using jina-embeddings-v4 model.
  • Update UI to select Jina as provider and enter API key.
• Configuration:
  • Add Jina to codebaseIndexConfigSchema and codebaseIndexModelsSchema in codebase-index.ts.
  • Add Jina API key handling in global-settings.ts and webviewMessageHandler.ts.
• Validation and Localization:
  • Add Jina-related validation messages in embeddings.json.
  • Add localization support for Jina in settings.json.
• Misc:
  • Update service-factory.ts to create JinaEmbedder instance.
  • Add Jina model profiles to embeddingModels.ts.

^{This description was created by for b56695e. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Thanks a bunch for adding Jina as an embedding provider! The implementation follows the existing patterns nicely and includes proper internationalization. But, I noticed that the critical issue from the previous review about missing secret status handling is still not resolved, along with a few other things that need our attention. Can you take a look?

[daniel-lxs]

Critical Issue: The updateWithSecrets function is missing handling for codebaseIndexJinaApiKey. This prevents the UI from properly showing placeholder values for existing Jina API keys. You need to add this handling similar to other providers around line 320.

[daniel-lxs]

Missing telemetry implementation. Other embedders (OpenAI, Mistral, Gemini) use TelemetryService.instance.captureEvent for error tracking. Could you add actual telemetry here instead of just comments?

Example:

Suggested change

	// Log telemetry for successful embedding creation
	TelemetryService.instance.captureEvent(TelemetryEventName.CODE_INDEX_ERROR, {
	error: lastError instanceof Error ? lastError.message : String(lastError),
	stack: lastError instanceof Error ? lastError.stack : undefined,
	location: "JinaEmbedder:createEmbeddings",
	attempt: attempt
	});

[daniel-lxs]

Is the hardcoded task: "code.query" intentional? While it makes sense for code-specific embeddings, would it be beneficial to make this configurable for future flexibility, perhaps as an optional parameter or class property?

[daniel-lxs]

The error handling pattern here differs from other embedders. While validateConfiguration uses withValidationErrorHandling, the createEmbeddings method implements its own retry logic. Consider aligning with the established error handling approach used in other embedders for consistency. Would it make sense to extract the retry logic into a shared helper similar to OpenAI's _embedBatchWithRetries?