Use light.adjust for active light groups

[dankarization]

Summary

Updates HA light group UI controls to call light.adjust for attribute-only changes when interacting with active Home Assistant light groups.

This keeps current behavior for off targets:

• active HA light groups use light.adjust
• off or fully-off groups continue to use light.turn_on
• non-group lights continue using existing light.turn_on semantics

This PR is paired with the backend implementation in core:

• Companion core PR: Add light.adjust service/action core#1

The user-facing rationale and proposal shape were described in the recent architecture discussion comment:

• Architecture discussion comment: Add `light.adjust` service call home-assistant/architecture#537 (comment)

Why

The more-info and Lovelace light controls currently express a user intent closer to "adjust the lights that are already active in this group" than "turn on every light in the group".

Without a more precise backend action, sliders and color controls on partially-on groups end up waking lights that are off. This PR switches those group-only attribute controls to the new light.adjust action, which matches the intended semantics.

What Changed

• add computeLightAttributeService helper in src/data/light.ts
• use that helper from:
  • more-info brightness controls
  • more-info color temperature controls
  • more-info RGB/favorite color controls
  • Lovelace light card features
  • state control brightness UI
• only choose light.adjust for Home Assistant light groups that expose attributes.entity_id
• keep light.turn_on behavior for off/all-off groups and non-group lights

Edge Cases Resolved

• partially-on HA light groups now adjust only active members instead of waking lights that are off
• fully-off groups still stay on normal light.turn_on semantics so power-on UX remains unchanged
• all: true group flows are aligned with the backend adjust semantics and current active-member selection
• Home Assistant light groups with member entities are detected explicitly, while ordinary lights and non-HA groups stay on the existing call path
• brightness, color temperature, RGB, favorite color, Lovelace, and state-control entry points all route through the same service-choice helper

Relation To Core

This frontend change depends on the new light.adjust service/action from the companion core PR. The two PRs are intentionally linked and should be reviewed together.

The backend/core PR defines the semantics:

• off lights default to no-op
• active HA light groups expand only to currently-on members
• service metadata makes the action render as a normal human-readable action in the UI

Testing

• Prettier / local formatting check on changed frontend files
• test/data/light.test.ts
• live HOME HA verification against the paired core patch:
  • partially-on group brightness changes no longer turned on off members
  • all-off groups still used normal turn-on semantics

References

• Architecture discussion: Add `light.adjust` service call home-assistant/architecture#537
• Recent proposal comment used as the rationale baseline: Add `light.adjust` service call home-assistant/architecture#537 (comment)
• Companion core PR: Add light.adjust service/action core#1

[dankarization]

@codex review этого кода, учитывая что в HA эта тема щепетильная и меня будут терроризировать на точность, аккуратность, лишность и тд.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: af5c4d54c9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dankarization]

@codex rereview all other code until you find everything.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: af5c4d54c9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dankarization]

@codex review new fix

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 45e9d78a47

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Recurse into nested light groups before falling back

The new direct-member check still misses partially-on nested light groups: if a group contains another all: true light group whose own aggregate state is off while one of its child lights is on, none of the immediate memberIds are on, so this returns turn_on and the subsequent brightness/color adjustment wakes the off grandchildren. This leaves the same “partial group turns on everything” regression for users who organize light groups hierarchically; the active-member test needs to expand member groups recursively or otherwise defer the decision to the backend adjust semantics.

Useful? React with 👍 / 👎.