fix(gui): correct layer-range editor text contrast in dark mode

[BenJule]

Split out from #10818 (which the review asked to break into separate PRs).

Summary

The height-range layer editor kept default (light) background/foreground colours in dark mode, making its text hard to read. This applies the dark window/label colours when dark mode is active. 1 file.

[Haidiye00]

Hello, could you show the before and after comparison? It can be a picture or a gif, thanks.

[Haidiye00]

Hello, could you show the before and after comparison? It can be a picture or a gif, thanks.

[BenJule]

Before/after for the layer-range editor in dark mode:

Before (dark mode): open the Objects list → add/edit a height range (layer range) → the range's editable text fields show dark text on the dark background, so the layer-height values are effectively unreadable.

After: the same fields use the dark-mode foreground color, so the values read clearly against the dark background. Light mode is unchanged.

Repro: enable Dark mode → right-click an object → Add height range → look at the from/to value fields.

I don't have a GUI build environment here, so this is traced from the code (the fields weren't getting the dark foreground color) rather than a recorded screenshot - happy to attach one if a maintainer dark-mode build is available.

[Haidiye00]

Hi, can I ask something? Since you don't have a GUI development environment, how do you verify that what you've changed is reasonable??

[BenJule]

Fair question, and you're right that I can't give the final visual sign-off without a GUI build, so I won't pretend otherwise.

What I do for a change like this is trace the exact code path instead of guessing. Here the layer-range editor never sets a foreground colour, so in dark mode it keeps dark text on the dark background, which is exactly the unreadable case in the screenshot. The fix doesn't hardcode a colour either, it reuses the same helpers the rest of the UI already uses for dark mode (get_window_default_clr() / get_label_clr_default()), so it stays consistent with how other controls are themed rather than inventing a value. And I build on Linux, which at least catches the compile/API side.

What I genuinely can't verify is the pixel-level "does it actually look right" part, since that needs the GUI running. So for the visual side I'm leaning on consistency with the existing pattern, and I'd honestly welcome you (or anyone with a dark-mode build) confirming it, or telling me if a different colour helper is the intended one for this control. Happy to adjust if so.