feat: dim HDR-dependent settings and remove HDR toggle

[Eclipse-Dominator]

Fixes #41

Changes

1. Dim HDR-dependent controls when CM isn't HDR-capable

Controls under the HDR/EDID Override group (SDR EOTF, luminance fields, etc.) as well as some other settings only affect the visual output when Color Management is set to a potential HDR-capable preset (auto, hdr, or hdredid). They now get the dim-label CSS class when CM is set to any other value, indicating their values won't be relevant — while remaining modifiable. (auto is included because Hyprland have an auto hdr setting)

• properties_panel.py — Added _hdr_dependent_rows list collecting relevant widgets
• properties_panel.py — Added _set_rows_dimmed helper and _sync_hdr_dependent_setting_dimming sync method
• Syncs on profile load (update_from_monitor) and on every property change (_on_changed)

2. Remove standalone HDR toggle

color_management = "hdr" already produces the same config output as the old hdr: true toggle. The standalone switch (_sw_hdr) was redundant with the Color Management dropdown and potentially confusing.

• models.py — Removed hdr: bool from MonitorConfig
• models.py — Simplified config output: cm = self.color_management (removed the ("hdr" if self.hdr else "") fallback in both legacy and Lua paths)
• models.py — Added legacy migration in Profile.from_dict: profiles with "hdr": true and no explicit CM are auto-converted to color_management: "hdr" on load
• properties_panel.py — Removed _sw_hdr widget creation, set_active, and get_active

Tests

Added tests/test_hdr_migration.py covering:

• Legacy hdr: true without CM → color_management: "hdr"
• Explicit CM takes priority over hdr: true
• No hdr key → unchanged
• hdr: false → unchanged
• Round-trip preserves migrated value, hdr not present in serialized output
• Multiple monitors migrate independently

---

For ux wise I feel that tooltips/hints could be add to address why they are dimmed and that changing cm to a hdr capable mode would resolve it. For users who never touched color mode and only used hdr toggles. This change should auto migrate existing profiles over but for creating new profiles, users who aren't sure of cm could be confused.

I have some considerations which is why I have yet to implement the tooltips. As of now none of the widget that is affect by this commit uses tooltips, so _set_rows_dimmed can have an optional field to include tooltips and remove it otherwise, but to account for potential future uses if something does have a preset tooltip, it would mean that dimming/undimming it would replace/removing the existing tooltips. The workaround would be to cache their original tooltip or using an append to the existing tooltips.

Alternative would be a toast that would be displayed once (per profile?/per session) when the user tried to change some of the dimmed field.

[Eclipse-Dominator]

Update:
I recalled cm_auto_hdr could convert to hdr even on sdr cm modes, which means the dimming of text might be a bit too intrusive from a UX standpoint.

I made a new PR #44, which uses hints over the row dimming to have a less intrusive UX (as an alternative approach). I think the other might overall be better than full row dimming approach here? Do check it out.

An alternative could be to just dim the text and not the controls and add the tooltip? Like what was doing in #44.

[ToRvaLDz]

Closing in favor of #44, which is the refined alternative you proposed here: subtitle + tooltip hints instead of full dimming, so the HDR-dependent fields stay legible and explain themselves. Thank you for both approaches, and sorry again for the delay.