Fix disabled ComboBox rendering to use system disabled palette in modern visual styles

[LeafShi1]

Fixes #14797

Root cause

ComboBox.ModernComboAdapter computed its disabled appearance by muting the control's own BackColor/ForeColor ``(Mute(BackColor, 0.55f)) rather than using a fixed system disabled palette. Because the muted result is derived from user colors, a ComboBox with a custom BackColor still looked "colored" when disabled

Separately, ComboBox did not handle WM_CTLCOLORSTATIC for the native edit child. When disabled, Windows fell back to its default white background, which did not match the disabled surface the adapter painted for the rest of the field.

Proposed changes

• Adds a shared disabled color palette to ModernControlColorMath (dark-mode and high-contrast aware) and makes the modern ComboBox adapter, the ComboBox WM_CTLCOLORSTATIC handler, and the modern Button renderers all read from it, so disabled controls stay visually consistent.

Customer Impact

• A disabled ComboBox in modern visual styles now looks disabled: it uses the system disabled surface, border, and text colors instead of a washed-out version of the developer's custom colors. This makes the disabled state immediately recognizable and consistent with disabled Button and other modern controls, in both light and dark mode, and it resolves the white edit-field box previously visible in DropDown style.

Regression?

• No

Risk

• Minimal

Screenshots

Before

Light mode:

Dark mode:

After

Light mode:

Dark mode:

Test methodology

• Unit test and manual tests

Test environment(s)

• .net11.0.0-preview.7.26365.101

Microsoft Reviewers: Open in CodeFlow

[KlausLoeffelmann]

It's just the one missing line - and I do not want to block this over that line, so, let's take this without addressing this. (The world will go on...)

But - let's make sure, we have a process, where we maintain both skills for code generation and code reviewing, so that those kinds of edits will be a thing of the past in a few months. 😸