[DRY/KISS] Extract form layout construction from WinForms behavior

[KeyffMS]

Audit finding

ConfigurationForm, VisualProfileManagerForm and VisualProfileEditorForm still combine application interaction logic with large imperative control-tree construction methods. Shared presentation primitives already exist, but each form remains responsible for composing headers, cards, action bars, grids and fixed layout measurements alongside event and commit handling.

This makes behavioral reviews harder because application-flow changes and visual-layout changes converge in the same classes.

Target state

Move stable control-tree construction into focused internal builders or view components while keeping interaction behavior in the forms.

The refactor should remain idiomatic WinForms. Do not add MVVM, a designer-code generator or a custom UI framework.

Acceptance criteria

• Each affected form has a clearly separated layout-construction boundary.
• Form classes remain responsible for event handling, dialogs, rendering snapshots and presenting command results.
• Reusable card/header/action-bar construction uses existing FormPresentation and theme authorities rather than new duplicate helpers.
• Layout constants that represent the same product rule have one named source.
• Existing accessibility names, tab/focus behavior, minimum sizes, anchoring and DPI behavior remain unchanged.
• Existing profile refresh and configuration use-case tests continue to pass.
• No broad inheritance hierarchy for forms is introduced.