Fix icons of PropertyGrid control are not scaled well on 100% secondary monitor

[ricardobossan]

Fixes #8268

Proposed changes

PropertyGrid's toolbar icons (sort-alphabetically / sort-by-category / property-pages buttons) didn't rescale correctly after a PerMonitorV2 DPI change. Root-caused to two independent, stacked defects in the toolbar rebuild path (PropertyGrid.SetupToolbar/CreatePushButton):

• SetupToolbar() rebuilt the toolbar's ImageList at the new DPI but never updated ToolStrip.ImageScalingSize (what actually drives rendered icon size), and the ImageList.ImageSize assignment itself was gated on ScaleHelper.IsScalingRequired, which only reflects the process's startup DPI rather than whether the app is PerMonitorV2-aware. Fixed by always setting ImageScalingSize right after the ImageList is rebuilt; before any button is created, since a ToolStripItem's size is computed once and never revisited later; and switching to ScaleHelper.IsScalingRequirementMet.
• ToolStripItem/ToolStripButton bake their default Margin and minimum button width from ScaleHelper.InitialSystemDpi (again the process's startup DPI) at construction time, so a button (re)created after a runtime DPI change still inherits sizing baked in for whatever DPI the process happened to start at. Fixed by having CreatePushButton explicitly re-apply Margin and DeviceDpi using the grid's current DPI; DeviceDpi routes through ToolStripButton's own already-correct DeviceDpi setter override, which recomputes the minimum width but was never being invoked for ordinary toolbar buttons.

Together these explain the issue's reported asymmetry: sizing baked in for a higher DPI and later applied at a lower one is very visibly wrong (oversized icons/buttons); the reverse just leaves a little extra room, so it's easy to miss.

Customer Impact

• Apps using PerMonitorV2 render PropertyGrid toolbar icons at the wrong size after the app moves between monitors with different DPI, until the process restarts. Visual/readability issue only; the grid remains fully usable.

Regression?

• Yes, relative to .NET Framework; not a regression within .NET Core/5+ (reproduces on .NET 6/7/8 alike per the issue).

Risk

• All changes are scoped to PropertyGrid's own toolbar-button construction/rebuild path; none affect SystemAware/DpiUnaware apps or any other control. The DeviceDpi/IsScalingRequirementMet changes invoke existing, already-correct framework code paths rather than introducing new logic.

Before

• Started form at 100% scale and took screenshot at 225. Blurry icons:

• Started form at 225% scale and took screenshot at 100. Buttons stretched horizontally:

After

• Started form at 100% scale and took screenshot at 225. Crisp icons:

• Started form at 225% scale and took screenshot at 100. buttons sized accordingly:

Test environment

11.0.100-preview.5.26302.115

Microsoft Reviewers: Open in CodeFlow

[SimonZhao888]

LGTM! Could you please check the following:

1. Whether the toolbar buttons become briefly misaligned when dragging the window back and forth between multiple monitors with different scaling settings.
2. Whether the icon sizes remain consistent after switching between 100% DPI and high DPI.

[ricardobossan]

LGTM! Could you please check the following:

1. Whether the toolbar buttons become briefly misaligned when dragging the window back and forth between multiple monitors with different scaling settings.
2. Whether the icon sizes remain consistent after switching between 100% DPI and high DPI.

@SimonZhao888 Thanks for checking, both confirmed now with the actual repro app across real monitors at different scales:

1. Dragging the window between monitors with different scaling: no misalignment during or after the transition, toolbar buttons stayed correctly positioned throughout.
2. Icon sizes: stayed consistent and crisp switching between 100% and high DPI, both directions.

Both should be good to go.