Retry setup when vehicle base data is incomplete

[ML19821]

Fixes #393.

get_stored_overview() in pyporscheconnectapi catches PorscheExceptionError internally and returns normally, so a rate limited API leaves vehicle.data without the base data it would have merged in — including name. No exception reaches the coordinator, so the refresh counts as successful, and entity setup then raises KeyError: 'name' in every platform. Home Assistant does not retry platform setup after that, so the integration ends up with a loaded config entry and zero entities until someone reloads it by hand.

This detects the incomplete data in the coordinator and fails the refresh instead. During setup async_config_entry_first_refresh() converts UpdateFailed into ConfigEntryNotReady, so Home Assistant retries with backoff and the integration recovers on its own once the API responds again.

self.vehicles is reset so the retry refetches, rather than falling into the else branch below, which would never call get_picture_locations() again.

Why not a fallback for vehicle.data["name"]

That was my first instinct, but sensor.py builds unique_id from the same value. A fallback would mint different unique IDs whenever the data is incomplete and leave duplicate entities behind once the API recovers. Not creating entities from incomplete data at all avoids the problem instead of trading it for a subtler one.

Testing

Isolated tests of the guard (complete data, missing base data, two vehicles with one incomplete, both incomplete, empty vehicle list, empty-string name) all behave as intended.

End-to-end on a live installation, simulating the swallowed failure with vehicle.data.pop("name", None) after the overview call:

• before: KeyError: 'name' in sensor, binary_sensor, device_tracker, lock and image; config entry loaded, no entities, no recovery
• after: config entry setup_retry, reason Incomplete data for vehicle(s) <vin>, will retry, automatic retries

With the simulation removed and normal API responses, all entities come back unchanged — no change to unique IDs or entity IDs.

Note

Arguably get_stored_overview() should let the exception propagate rather than swallow it; the coordinator already handles PorscheExceptionError correctly. That is the more complete fix but touches pyporscheconnectapi, so it is not part of this PR.