Claude review: drm/amd/display: use plane color_mgmt_changed to track colorop changes

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Assessment: Good, straightforward driver-side consumer**

This wires the new `color_mgmt_changed` flag into the AMD display driver at two critical points:

1. **`amdgpu_dm_commit_planes()`**: The color surface updates (gamma, transfer func, gamut remap, HDR mult, shaper, 3D LUT, blend TF) now also trigger when `new_plane_state->color_mgmt_changed` is set:
```c
if (new_pcrtc_state->color_mgmt_changed || new_plane_state->color_mgmt_changed) {
```
This is the actual bug fix — without this, changing colorop properties (like shaper/3D LUT for night mode) wouldn't cause DC to reprogram the color blocks.

2. **`should_reset_plane()`**: Returns true when `new_plane_state->color_mgmt_changed` is set, causing plane reset during atomic check. This ensures the DC plane state is fully recreated when colorop properties change.

Both additions are consistent with the existing CRTC `color_mgmt_changed` pattern. The comment `/* Plane color pipeline or its colorop changes. */` is appropriate.

Harry's R-b tag from v1 carried forward is noted.

**One question for the maintainer**: `should_reset_plane()` returning true can trigger full plane recreation which is relatively expensive. For the gamescope night mode use case (shaper/3D LUT data changes), this should be fine since it happens on user-initiated actions, not per-frame. But if a compositor were to update colorop properties every frame, this could cause performance issues. The existing CRTC `color_mgmt_changed` path has the same characteristic, so this is consistent, but worth keeping in mind.

---
Generated by Claude Code Patch Reviewer