[SPoT/DRY] Create one canonical registry for built-in visual profiles and transforms

[github-actions]

Audit finding

Built-in visual-profile knowledge is repeated across several authorities:

• SightAdaptSettings manually constructs the default profile collection.
• VisualProfile declares built-in IDs and factory methods.
• VisualProfilePolicy.IsBuiltInId manually lists the same IDs.
• VisualProfileDefaults separately defines names, factories, canonicalization and tuning.
• VisualTransformCatalog separately lists transform IDs, names and tuning capability.
• UI notifications still hard-code the Soft invert name.

This makes adding or changing a built-in profile a multi-file synchronization task and violates DRY and Single Point of Truth.

Target state

Introduce one immutable canonical definition registry for built-in profiles. A definition should contain the stable profile ID, display name, transform ID, editability/tuning capability and factory/canonicalization data needed by the product.

The registry should drive:

• creation of default settings;
• built-in-ID recognition;
• profile canonicalization;
• transform/profile compatibility;
• selector display metadata;
• default and fallback policy validation.

Use OverlayScopePolicy as the design reference: one definition table from which lookup structures and public policy are derived.

Acceptance criteria

• A single canonical collection defines every built-in visual profile.
• Default settings, built-in checks and normalization are derived from that collection.
• Adding a built-in profile does not require editing multiple manual ID/name lists.
• Default-profile messages resolve their display name through policy rather than hard-coded UI text.
• Tests prove unique IDs, valid transform references, stable ordering and correct default/fallback references.
• Existing settings remain compatible.