feat: add expand_light_groups option

[hesseleo]

Some light group entities act as a proxy that must receive a single combined light.turn_on call to function correctly — virtual mixers like https://github.com/mion00/color-temperature-light-mixer for instance, that blend a warm and a cold white channel into one entity. In such setups the individual member entities only expose ColorMode.BRIGHTNESS, so sending separate per-member commands bypasses the mixing logic.

Setting expand_light_groups: false keeps the group entity in self.lights instead of expanding it to its members. Adaptation commands go to the group, and the interceptor no longer skips group entities for that switch.

Default is true — no behaviour change for existing configurations.

[basnijholt]

Sorry it took me so long to get to this. I've been a bit overwhelmed by the number of AI-assisted PRs opened here recently, and I've also been spending nearly every spare hour on my biggest project so far, MindRoom.

I'm very supportive of using AI for coding, but many of these PRs still need careful human review because even plausible-looking changes can introduce subtle breakage. That backlog made me postpone reviewing them for a while.

I've now done a batch review with Codex / GPT-5.5 (xhigh). This comment is AI-assisted, but I've reviewed the concern before posting it.

I found a likely bug in the reactive/off-to-on path when expand_light_groups is disabled.

The interceptor path was adjusted to respect the new flag, but state_changed_event_listener still does:

switches = _switches_with_lights(self.hass, [entity_id])

That helper uses the default group-expansion behavior. When expand_light_groups: false, switch.lights contains the group entity, but this lookup expands the state-change entity to the child lights before intersecting with the switch's lights. The result is that the switch may not be found, so the off-to-on reactive adaptation path does not adapt the group.

Could you make this lookup respect the switch's expand_light_groups setting, or otherwise avoid expanding the event entity for this case? A regression test with a light group and expand_light_groups: false would be very useful here.

[hesseleo]

Thank you for the careful review — and I'm sorry for taking even longer to reply.

I fixed the bug in _switches_with_lights by checking each switch's own expand_light_groups flag before expanding the incoming entity ID, so a switch storing the group entity directly now correctly matches and I added a regression test as recommended.

I did an amend for the fix and a separate commit for the test — hope that's fine.