Fix options page redraw artifacts

[bitRAKE]

Summary

Fixes dirty/stale background artifacts when switching to some plugin Options pages.

The fix:

• Redraws the Options dialog container before redrawing the selected page.
• Clears WS_CLIPCHILDREN on plugin option pages whose group-box regions exposed stale backing pixels:
  • NetworkTools
  • OnlineChecks
  • ExtendedNotifications Logging

Problem

Some Options pages showed stale pixels from previously selected pages inside group-box areas. The controls from the previous page were not active; this was a redraw artifact.

Confirmed affected pages:

• Network Tools
• Online Checks
• ExtendedNotifications - Logging

Investigation signals

The issue was narrowed down through several visual checks:

• Switching to other Options pages and then back showed stale content only in specific group-box regions.
• The controls from the previous page were not interactive, confirming this was not a page merge or visibility issue.
• The bottom/non-group-box area of the page cleared correctly, which indicated the page/container was partially repainting.
• Updater did not reproduce because it has a sparse page without the same group-box/layout combination.
• ToolStatus has group boxes but did not show the same behavior because it does not use the same layout-manager path.
• ExtendedNotifications Logging reproduced the same issue, confirming this was not specific to NetworkTools or OnlineChecks.

Several probes helped isolate the cause:

• Adding WS_EX_TRANSPARENT to affected group boxes did not fix the artifact.
• Changing themed group-box paint/erase behavior did not fix the artifact.
• Clearing WS_CLIPCHILDREN alone did not fix the artifact.
• Redrawing the Options container cleared the stale pixels, but exposed the default grey dialog background in group-box regions.
• Combining the container redraw with clearing WS_CLIPCHILDREN on the affected page roots produced the correct visual result.

Validation

• x64 local visual inspection:
  • Network Tools page
  • Online Checks page
  • ExtendedNotifications Logging page

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[bitRAKE]

I have read the CLA Document and I hereby sign the CLA

[bitRAKE]

The risky part is the global side effect in PhInitializeLayoutManager: every dialog/page using the layout manager silently inherits WS_CLIPCHILDREN. That is broad enough to expose stale-paint behavior in pages that were never designed around it, especially transparent group boxes. If only one plugin/dialog needed the clipping workaround, applying it locally there is easier to reason about.

Best upstream shape is maybe one of these:

1. Revert the global WS_CLIPCHILDREN | WS_CLIPSIBLINGS change.
2. Reintroduce it as an explicit opt-in layout flag, like the commented PH_LAYOUT_INIT_CLIP_CHILDREN path suggested.
3. Apply the clipping style only to the specific plugin/window that needs it.

This fix is still useful evidence that identifies the affected class of pages and confirms the mechanism.