feat: implement dynamic retry timing for Google Gemini API

[roomote]

This PR implements dynamic retry timing for the Google Gemini API based on the retry delay information returned in API responses. This addresses issue #6680 where users were experiencing unnecessary rate limit errors when the API provides specific retry timing information.

Changes:

• Enhanced error handling in GeminiHandler to preserve the original error structure
• Added logic to distinguish between temporary rate limits and quota exhaustion
• Preserved retry delay information from Gemini API responses
• Added new localized error messages for better user feedback
• Added comprehensive tests for all new error handling scenarios

Fixes #6680

---

Important

Implements dynamic retry timing for Google Gemini API in GeminiHandler, enhancing error handling and adding tests for rate limit and quota exhaustion scenarios.

• Behavior:
  • Implements dynamic retry timing in GeminiHandler for Google Gemini API using retry delay from API responses.
  • Distinguishes between rate limit and quota exhaustion errors.
  • Preserves original error structure for retry logic.
• Error Handling:
  • Adds new localized error messages in common.json for rate limit and quota exhaustion.
  • Enhances error handling in GeminiHandler to preserve error details.
• Testing:
  • Adds tests in gemini.spec.ts for rate limit and quota exhaustion scenarios.
  • Tests ensure retry information is preserved and correct errors are thrown.

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

[ellipsis-dev]

The error handling logic for HTTP 429 is duplicated in both the createMessage and completePrompt methods. Consider extracting this logic into a shared helper function to reduce duplication and improve maintainability.

[roomote]

I wrote this code and even I'm not sure why it works.

[roomote]

This error handling logic is duplicated between createMessage() and completePrompt(). Could we extract this into a private method like handleGeminiError(error: any): Error to follow DRY principles?

Suggested change

	if (error.status === 429) {
	private handleGeminiError(error: any): Error {
	// Preserve the original error structure for retry logic
	if (error.status === 429) {
	// Check if this is a rate limit or quota exhaustion
	const errorMessage = error.message || ""
	const isQuotaExhausted = errorMessage.includes("quota") || errorMessage.includes("billing")
	// Create an enhanced error that preserves the original structure
	const enhancedError = new Error(
	isQuotaExhausted
	? t("common:errors.gemini.quota_exhausted", { error: errorMessage })
	: t("common:errors.gemini.rate_limit", { error: errorMessage }),
	)
	// Preserve ALL original error properties for retry logic
	Object.assign(enhancedError, error)
	throw enhancedError
	}
	if (error instanceof Error) {
	throw new Error(t("common:errors.gemini.generate_stream", { error: error.message }))
	}
	throw error
	}

[roomote]

Is this intentional? The enhanced error only preserves status, errorDetails, and message. What if the original error has other properties that the retry logic depends on? Consider using Object.assign(enhancedError, error) to preserve all properties.

[roomote]

These new error messages are only added to the English locale. Could we add placeholder translations to all other locale files (ca, de, es, fr, etc.) to maintain consistency? Even if they're in English temporarily, it prevents runtime errors for non-English users.

[roomote]

This test verifies that error properties are preserved, but it doesn't check if the enhanced error message is correctly set. Could we add an assertion like:

Suggested change

	expect(error.status).toBe(429)
	expect(error.message).toContain("Gemini API rate limit exceeded")

[daniel-lxs]

This doesn't seem quite right, closing for now until we scope the issue correctly