fix(vehicle): handle :too_many_request in list_vehicles! and fetch_strict

Testing the previous commit against a live EXCEEDED_LIMIT ban surfaced
two spots where {:error, :too_many_request, retry_after} was never
handled, even though this shape already existed for plain HTTP 429s:

- Vehicles.list_vehicles!/0 (called once at application boot) had no
  matching case clause, so a rate-limited "list vehicles" call crashed
  the whole application at startup - and with restart: always, that's
  a boot-crash-loop that keeps calling the rate-limited endpoint.
- Vehicle.fetch_strict/2 (used by the manual "suspend logging" action)
  had the same gap, which would crash that vehicle's process if
  triggered while rate-limited.

Both now fall back gracefully instead of crashing: list_vehicles! uses
its existing fallback_vehicles() (cached cars from the DB), and
fetch_strict returns {:error, {:too_many_request, retry_after}} in the
same {:error, reason} shape its one caller already expects.

Author: hossamnagy

lib/teslamate/vehicles.ex

@@ -83,6 +83,10 @@ defmodule TeslaMate.Vehicles do
       {:error, :not_signed_in} ->
         fallback_vehicles()
 
+      {:error, :too_many_request, retry_after} ->
+        Logger.warning("Could not get vehicles: rate limited, retry after #{retry_after}s")
+        fallback_vehicles()
+
       {:error, reason} ->
         Logger.warning("Could not get vehicles: #{inspect(reason)}")
         fallback_vehicles()

lib/teslamate/vehicles/vehicle.ex

@@ -1558,6 +1558,9 @@ defmodule TeslaMate.Vehicles.Vehicle do
       {:ok, %V{}} ->
         {:error, :gateway_error}
 
+      {:error, :too_many_request, retry_after} ->
+        {:error, {:too_many_request, retry_after}}
+
       {:error, reason} ->
         {:error, reason}
     end