fix(antigravity): 🐛 add fallback retry logic for RESOURCE_EXHAUSTED errors without timing details

Previously, the error parsing logic would return None if the API response didn't include explicit retry timing details, even when the error clearly indicated resource exhaustion (HTTP 429 or RESOURCE_EXHAUSTED status). This caused the retry mechanism to fail silently.

- Removed the early return when details array is empty, allowing further error processing
- Added detection for bare RESOURCE_EXHAUSTED errors (status code or HTTP 429)
- Set a sensible 60-second default retry_after when timing details are missing
- Ensures retry mechanism engages even with minimal error response data

This improves resilience when the Antigravity API returns resource exhaustion errors without structured retry timing information.

src/rotator_library/providers/antigravity_provider.py

@@ -673,9 +673,6 @@ class AntigravityProvider(AntigravityAuthBase, ProviderInterface):
         error_obj = data.get("error", data)
         details = error_obj.get("details", [])
 
-        if not details:
-            return None
-
         result = {
             "retry_after": None,
             "reason": None,
@@ -726,6 +723,15 @@ class AntigravityProvider(AntigravityAuthBase, ProviderInterface):
 
         # Return None if we couldn't extract retry_after
         if not result["retry_after"]:
+            # Handle bare RESOURCE_EXHAUSTED without timing details
+            error_status = error_obj.get("status", "")
+            error_code = error_obj.get("code")
+
+            if error_status == "RESOURCE_EXHAUSTED" or error_code == 429:
+                result["retry_after"] = 60  # Default fallback
+                result["reason"] = result.get("reason") or "RESOURCE_EXHAUSTED"
+                return result
+
             return None
 
         return result