test(ha): verify generic valve discovery and migration

[MaxRink]

Summary

Verify that switch exposes can already be discovered as Home Assistant MQTT valves through the existing generic homeassistant.type metadata and ZHC overrideHaDiscoveryPayload callback. The final change adds integration tests only: the valve-specific Zigbee2MQTT discovery branch has been removed.

The tests cover ordinary and endpoint-scoped valves, ON/OFF open/close payloads and states, endpoint command topics, stable discovery object IDs and unique IDs, and removal of the previous retained switch discovery.

Migration

Changing the Home Assistant component from switch to valve creates a different entity-domain identity even with the same unique_id. Home Assistant's registry keys entries by (domain, platform, unique_id): https://github.com/home-assistant/core/blob/dev/homeassistant/helpers/entity_registry.py

The tests verify removal of the old retained switch discovery; they do not claim to preserve the old Home Assistant entity registry entry. Existing automations and dashboards referencing the switch entity need migration. No live Home Assistant instance was used.

Paired converter change

Koenkk/zigbee-herdsman-converters#13232 enables the existing metadata and callback for SONOFF SWV-ZFE/ZFU, SWV-ZF2 and SWV-ZNE/ZNU. This test-only PR does not activate device behavior by itself.

Validation

• Node 24 build and Biome checks passed.
• All 93 Home Assistant tests passed, including both new migration/discovery cases.
• Full suite with coverage passed outside the sandbox: 826 tests across 25 files; 100% statements, branches, functions and lines (Node 24, two workers, 60-second test timeout).

[Koenkk]

Given that the object_id changes, I believe this is a breaking change?

[MaxRink]

Yes, changing the Home Assistant discovery component from switch to valve is still a migration to call out.

I adjusted the implementation so the old object ID shape is preserved (switch / switch_<endpoint>). That avoids an extra entity rename on top of the intended component/domain change.

[Koenkk]

• Can you verify that with this change no new entity is created?
• I would prefer to introduce a more generic mechanism to change HA expose properties (e.g. directly on the expose itself in zhc instead of on meta)

[Koenkk]

Im wondering if we maybe can just do this through the override ha discovery payload which already exists in zhc?