Centralize remaining theme tokens and eliminate paint-path font leaks

[KeyffMS]

Priority

P3

Context

Found during a static DRY/KISS/SPoA/SPoT/Clean Code regression audit of main at commit 874b1d74381af65d3d95b955a5bea6c7680876a9 (0.5.0.30).

Problem

AppTheme centralizes most colors, but several semantic variants remain local Color.FromArgb values, including the alternating grid-row background and danger hover/pressed/border states in ModernButton.ResolveColors.

Changing the visual semantics of a danger control or alternate surface therefore requires editing multiple implementation details rather than one theme definition.

AppTheme.CreateUiFont creates a new Font object on every call. Most controls own these fonts through WinForms disposal, but fallback expressions in selector rendering/configuration can allocate fonts without explicit ownership, for example:

cellStyle.Font ?? AppTheme.CreateUiFont(9.5f)

In ModernSelectorComboBoxCell.Paint, this fallback occurs on a rendering path and the newly created font is not disposed.

Impact

• theme variants can drift from the central palette;
• changes to danger styling require multiple edits;
• paint-path fallback allocation can leak GDI font objects;
• font ownership is unclear at fallback call sites;
• adding controls encourages additional local color constants.

Proposed direction

1. Add semantic theme tokens for remaining variants, for example SurfaceAlternate, DangerHover, DangerPressed, and DangerBorder.
2. Replace local semantic Color.FromArgb values with these tokens.
3. Avoid allocating a font inside paint fallback expressions; use an existing owned control/grid/default font.
4. Review CreateUiFont call sites and ensure every created font is owned by a disposable component or explicitly disposed.
5. Keep the current simple static theme model; no theme framework is required.

Acceptance criteria

• all danger-state colors are defined in one theme authority;
• the alternating-row surface color is defined in the theme authority;
• selector paint paths do not allocate undisposed Font instances;
• every CreateUiFont result has clear ownership;
• visual behavior remains equivalent;
• a focused test or static rule prevents font creation in relevant paint methods.