Add light.adjust service/action

[dankarization]

Summary

Adds a new light.adjust service/action to the light domain for attribute-only light changes without turning on lights that are currently off.

This is implemented conservatively:

• off lights default to no-op
• on lights route through async_adjust
• Home Assistant light groups expand only to members that are currently on
• service metadata is included so the action is human-readable in the UI

This PR is paired with the frontend PR that calls light.adjust from group light controls:

• Companion frontend PR: Use light.adjust for active light groups frontend#52487

This proposal shape follows the recent architecture discussion comment:

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

Why

Recent frontend UX improvements made HA light groups a natural room-level control surface. In that UI, changing brightness or color-related attributes on a partially-on group should adjust the active lights in the group, not wake up members that are currently off.

Using light.turn_on for that intent is too broad because it inherently carries a power-on semantic. light.adjust gives the frontend and automations a precise action for "change attributes, but do not turn on currently-off lights".

What Changed

• add light.adjust service schema and handler
• add default LightEntity.async_adjust
• route active lights through adjust semantics without changing off lights
• make LightGroup.async_adjust target only currently-on members
• keep all-off group calls as no-op
• add service metadata in strings.json and icons.json
• add regression coverage for light groups and base light behavior

Edge Cases Resolved

• removed adjust-only selectors from light.turn_on metadata so the action UI does not advertise unsupported fields there
• copy filtered params before per-entity dispatch so custom async_adjust() handlers do not observe shared mutation across group members
• preserve per-member brightness_step and brightness_step_pct semantics when a group fans out to active members with different current brightness
• keep nested and all: true light groups on adjust-only semantics without waking members that are currently off
• preserve color_name when light.adjust is combined with step-based brightness changes on groups
• avoid applying default profiles from group-level process_turn_on_params() during custom group async_adjust() handling
• run zero-value rejection after unsupported brightness params are filtered so mixed-capability groups do not fail on ONOFF-only members

Relation To Frontend

This core change is intentionally paired with a frontend caller change. On its own, this PR provides the backend semantics and service metadata. The companion frontend PR updates group light controls to use light.adjust when the entity is a Home Assistant light group with member entities, while preserving light.turn_on for off or fully-off groups.

That frontend PR should land together with this one, or after this one.

Testing

• Python compile on changed core files
• services.yaml parse check
• git diff --check
• regression tests added in:
  • tests/components/group/test_light.py
  • tests/components/light/test_init.py

References

• Architecture discussion: Add `light.adjust` service call architecture#537
• Recent proposal comment used as the rationale baseline: Add `light.adjust` service call architecture#537 (comment)
• Companion frontend PR: Use light.adjust for active light groups frontend#52487

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (light) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of light can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant mark-draft Mark the pull request as draft.
• @home-assistant ready-for-review Remove the draft status from the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign light Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant update-branch Update the pull request branch with the base branch.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the pull request.

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (group) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of group can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant mark-draft Mark the pull request as draft.
• @home-assistant ready-for-review Remove the draft status from the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign group Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant update-branch Update the pull request branch with the base branch.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the pull request.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 55898c6ec5

ℹ️ 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]

Convert color params before filtering group adjust

When light.adjust targets a LightGroup, this branch filters the raw service params before running the normal color-space conversion. For an on group whose members support only HS/XY/color-temp/RGBWW, a documented field like rgb_color is removed by filter_turn_on_params() because the group itself does not support RGB, so params becomes empty and the adjust is silently skipped instead of being converted and forwarded to the active members. This means group adjust does not support the same color alternatives exposed in services.yaml and handled by light.turn_on.

Useful? React with 👍 / 👎.

[MartinHjelmare]

I'll close here since the architecture discussion isn't resolved.

Thanks for your willingness to contribute!

[dankarization]

Understood. Closing this pending architecture approval is fair.

I reworked the architecture discussion into the explicit proposal shape previously requested:
Background / Proposal / Consequences / Alternatives

Continuing here:
home-assistant/architecture#537

This PR can still serve as implementation/reference material, since it already covers the tricky group edge cases and shows the proposal is technically viable.