### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

In `_map_vertex_exception`, the branch `elif "403" in error_str:` is an **unanchored substring match against the whole serialized error body**, evaluated **before every 429 / quota / `RESOURCE_EXHAUSTED` branch**.

Google's AI Studio quota body carries a sub-second retry hint — `Please retry in 18.403470473s.` — whose digits contain `403`. So an ordinary HTTP 429 maps to `BadRequestError(status_code=403)`, while a byte-identical 429 whose retry delay lacks `403` maps correctly to `RateLimitError`:

``` retry delay 18.403470473s -> BadRequestError status_code=403 litellm._should_retry=False retry delay 18.9s -> RateLimitError status_code=429 litellm._should_retry=True ```

Since `_should_retry` is `False`, **litellm's own Router retry/fallback machinery declines to retry or fail over**, turning a transient rate limit into a hard 400-class failure. It is also nondeterministic: the outcome depends only on random decimals Google puts in the retry delay. We measured ~0.9% of Gemini 429s taking the wrong branch in production (3 of 328 …