DeviceIDError decorator coverage gaps: check_action_status + non-EU state reads

[blka]

Context

The _retry_on_device_id_error decorator (branch feature/device-id-retry-decorator) catches DeviceIDError (resCode 4002), re-registers a fresh device_id via notifications/register, and retries the call once — no re-login, no OTP. It replaces the previous proactive device_id rotation.

Methods currently decorated

• ApiImplType1 actions: lock_action, start_charge, stop_charge, start_climate, stop_climate, set_charge_limits, set_charging_current, schedule_charging_and_climate, set_windows_state, set_navigation, set_vehicle_to_load_discharge_limit, start_hazard_lights, start_hazard_lights_and_horn, get_vehicles
• KiaUvoApiEU: charge_port_action, force_refresh_vehicle_state, update_vehicle_with_cached_state, valet_mode_action

Coverage gaps — DeviceIDError can still escape

1. check_action_status is NOT decorated

check_action_status (ApiImplType1.py, base ApiImpl.py) is a known DeviceIDError source during EU action-status polling (refs: kia_uvo#1538, #672, #660). The decorator does not catch DeviceIDError raised while polling for action completion, so it still propagates to the caller.

2. Base ApiImpl state reads are NOT decorated (non-EU)

ApiImpl.update_vehicle_with_cached_state / force_refresh_vehicle_state (ApiImpl.py:178/199) are not decorated. KiaUvoApiEU overrides them (decorated), but non-EU Type1 regions (AU/IN/CN) that inherit the base versions are not covered — DeviceIDError on state reads for non-EU escapes. This may not matter if non-EU regions do not exhibit device_id invalidation (the fake-GCM push issue is primarily EU); needs confirmation before decorating.

3. CA / CN use a different _get_device_id(self) signature (no stamp)

The decorator calls self._get_stamp() + self._get_device_id(stamp). CA/CN have _get_device_id(self) without a stamp, so the decorator cannot be applied to them as-is. They are currently not covered (consistent with the EU focus), noted here for completeness.

Why scoped out of the decorator PR

• check_action_status DeviceIDError handling is intertwined with the deferred EU action-polling fix (DuplicateRequestError / empty resMsg on check_action_status) — same root cause (fake GCM push invalidating device_id). Best handled together with that fix rather than bolted on.
• Non-EU coverage should be confirmed (do those regions actually hit device_id invalidation?) before decorating, to avoid speculative changes.
• CA/CN would need a stamp-compatible _get_device_id or a separate recovery path.

Goal

Extend _retry_on_device_id_error coverage:

• check_action_status (Type1/EU), coordinated with the EU action-polling fix.
• Base ApiImpl state reads, if non-EU regions are confirmed affected.
• A stamp-compatible recovery path for CA/CN if needed.

Related

• kia_uvo#1683 — coordinator auto-recovery (the decorator makes the kia_uvo-side fix largely unnecessary for the EU first-refresh case)
• kia_uvo#1538, feat(EU): support valet mode #672, fix: stop warning on home assistant startup #660 — DeviceIDError reports
• hyundai_kia_connect_api#1143 — check_action_status empty resMsg due to stale device_id