feat: add action buttons for charge port, hazard, valet, and windows

[blka]

Summary

Adds 9 new action buttons for vehicle control operations.

New buttons

Key	Translation key	Type	Condition
open_charge_port	open_charge_port	Conditional	vehicle.ev_charge_port_door_is_open is not None
close_charge_port	close_charge_port	Conditional	vehicle.ev_charge_port_door_is_open is not None
start_hazard_lights	start_hazard_lights	Fire-and-forget	Always created
start_hazard_lights_and_horn	start_hazard_lights_and_horn	Fire-and-forget	Always created
start_valet_mode	start_valet_mode	Fire-and-forget	Always created
stop_valet_mode	stop_valet_mode	Fire-and-forget	Always created
open_all_windows	open_all_windows	Conditional	vehicle.front_left_window_is_open is not None
close_all_windows	close_all_windows	Conditional	vehicle.front_left_window_is_open is not None
vent_all_windows	vent_all_windows	Conditional	vehicle.front_left_window_is_open is not None

Fire-and-forget buttons (hazard, valet) are always created because they have no readable state. Conditional buttons only appear when the vehicle supports the related feature.

Changes

• button.py: Add 9 button descriptions with press_action mapping to coordinator methods
• coordinator.py: Add async_open_all_windows(), async_close_all_windows(), async_vent_all_windows() using WindowRequestOptions and WINDOW_STATE
• strings.json + translations/en.json: Translation keys for 9 buttons

Testing

Validated against live Hyundai EU API (Santa Fe HEV):

• 8/10 entities would be created (charge port buttons not created on HEV — ev_charge_port_door_is_open is None)
• Window button conditions met (front_left_window_is_open=0)
• All VehicleManager methods verified: open_charge_port, close_charge_port, start_hazard_lights, start_hazard_lights_and_horn, start_valet_mode, stop_valet_mode, set_windows_state

Depends on: #1641 (bug fixes), #1642 (cover — window coordinator methods)

Test plan

• Install on EV vehicle and verify charge port buttons appear
• Install on vehicle with window state and verify window buttons appear
• Test hazard lights and valet mode buttons
• Verify fire-and-forget buttons don't block on action status polling
• Install on HEV vehicle and verify charge port buttons don't appear

[cdnninja]

I thought windows was added as a cover entity?

Looks like some of these should be switches? Or would it be too slow from a response standpoint for things like hazard?

[cdnninja]

Is this worthwhile vs the existing window command?

[blka]

Good question. The existing set_windows service (via cover entity) controls individual windows with granular state. These button convenience methods are for the common case of "open all / close all / vent all" — one tap instead of adjusting each window cover individually.

The cover entity is the right UX for per-window control. The buttons are for quick bulk actions. Both use the same underlying set_windows_state API call, just with different WindowRequestOptions.

If you'd prefer these as switches instead of buttons (since they have a toggling feel for open/close), I can convert. But hazard lights and valet mode are fire-and-forget with no toggle state — buttons are the right entity type for those.

[blka]

?

[cdnninja]

Whenever on off exists with state it should not be a button.

[blka]

Hi @cdnninja, I've addressed all your feedback from the latest review:

1. exists_fn on button descriptions — Added exists_fn to HyundaiKiaButtonDescription so entities only show for vehicles that support them. Hazard lights use vehicle.supports_window_control is not None, windows use vehicle.front_left_window_is_open is not None. No more hardcoded if blocks in async_setup_entry.

2. Charge port → switch — Moved from button to switch. ev_charge_port_door_is_open has clear on/off state, so a switch is the correct entity type. on_fn = open, off_fn = close.

3. Valet mode → switch — Moved from button to switch. valet_mode_active has clear on/off state. on_fn = activate, off_fn = deactivate.

4. Windows stay as buttons — Windows have 3 states (closed/vent/open), so they don't map cleanly to binary on/off. vent_all_windows is also incremental — each press vents a bit more. Buttons are the right fit.

5. Hazard lights stay as buttons — Fire-and-forget action with no readable state. No on/off to toggle.

6. Clutter concern — The exists_fn pattern ensures entities only appear for vehicles that actually support each feature. Charge port switch appears only if ev_charge_port_door_is_open is not None, valet switch only if valet_mode_active is not None, etc.

Branch has been rebased onto latest master (conflicts resolved with the new charging schedule switches from #1710).

Ready for re-review.

[blka]

Rebased onto master. Changes since last review:

1. Removed duplicate _async_send_action — feat: add _async_send_action helper with action lock and UnsupportedControlError handling #1635 already merged this with action lock + UnsupportedControlError handling. This PR now only adds the net-new window convenience methods, which delegate to the existing helper.
2. Moved WINDOW_STATE import to top-level — no more inline imports per review feedback.

Regarding the window buttons vs cover entity question: the cover entity (set_windows service) is for per-window granular control. The open_all_windows / close_all_windows / vent_all_windows buttons are convenience shortcuts for the common "open everything / close everything" use case — one tap instead of adjusting 4 cover entities. Same underlying API call, different UX intent.

For hazard lights, valet mode, and charge port — these are fire-and-forget actions with no toggle state, so buttons are the correct entity type. Switches would imply a state that can be read back, which these don't have.

Marking as ready for review.

[blka]

@cdnninja if we are ok with all the fixes, could you take care or this PR?

[cdnninja]

A few more comments. I am a bit worried with some of these items adding clutter or adding them for those that can't use them due to model of car. How do we make sure this only shows for people who can use it?

[cdnninja]

Whenever on off exists with state it should not be a button.