docs: Add Themes and Skins migration strategy document

Evaluate 5 Blazor-native approaches to replicate Web Forms Themes and
Skins functionality: CSS Custom Properties, CascadingValue ThemeProvider,
Generated CSS Isolation, DI-based Configuration, and Hybrid.

Recommend CascadingValue ThemeProvider as the primary approach due to
full Web Forms fidelity (Theme/StyleSheetTheme semantics, SkinID support,
all property types). Document is exploratory per Jeff's request.

- Create docs/Migration/ThemesAndSkins.md with full analysis
- Add to mkdocs.yml nav under Migration section
- Record decision in .ai-team/decisions/inbox/
- Update forge history with learnings

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: csharpfritz

.ai-team/agents/forge/history.md

@@ -48,3 +48,14 @@ Evaluated 4 JS libraries for Chart component. D3 rejected (zero built-in charts,
 📌 Team update (2026-02-11): Milestone 3 gate review — DetailsView APPROVED, PasswordRecovery APPROVED. 50/53 (94%). — decided by Forge
 📌 Team update (2026-02-12): Chart component feasibility confirmed — Chart.js recommended via JS interop. Effort: L. Target Milestone 4. — decided by Forge
 📌 Team update (2026-02-12): Milestone 4 planned — Chart component with Chart.js via JS interop. 8 work items, design review required before implementation. — decided by Forge + Squad
+
+### Themes and Skins Migration Strategy (2026-02-12)
+
+- Evaluated 5 approaches for migrating Web Forms Themes/Skins to Blazor: CSS Custom Properties, CascadingValue ThemeProvider, Generated CSS Isolation, DI Service, and Hybrid.
+- **Recommended CascadingValue ThemeProvider** — only approach that faithfully models both `Theme` (override) and `StyleSheetTheme` (default) semantics, supports SkinID selection, and can set any property (not just CSS-expressible ones).
+- CSS-only approaches (1, 3, 5) cannot set non-CSS properties like `Width` (as HTML attribute), `ToolTip`, or `Visible` — which are valid skin properties in Web Forms.
+- DI-based approach (4) works functionally but cannot scope themes to a page or subtree, unlike `CascadingValue` which mirrors Web Forms' per-page `@Page Theme=` directive.
+- **Known bug:** `BaseWebFormsComponent.SkinID` is typed as `bool` instead of `string`. Must be fixed before any theme implementation.
+- The library already uses CascadingParameters extensively (TableItemStyle, LoginControl styles) — ThemeProvider follows the same pattern.
+- Implementation is opt-in and non-breaking: no `ThemeProvider` wrapper = no behavior change.
+- Strategy is exploratory per Jeff's request — the README exclusion of themes/skins still stands until a decision to implement.

.ai-team/decisions/inbox/forge-themes-skins-strategy.md

@@ -0,0 +1,14 @@
+### Themes and Skins Migration Strategy
+
+**By:** Forge
+**Date:** 2026-02-12
+**What:** Evaluated 5 approaches for migrating Web Forms Themes and Skins to Blazor. Recommended **CascadingValue ThemeProvider** (Approach 2) as the primary strategy. CSS Custom Properties are complementary but insufficient alone. Generated CSS Isolation rejected due to high tooling cost. DI-based approach rejected because it cannot scope themes to subtrees.
+
+**Key points:**
+- CascadingValue is the only approach that faithfully models both `Theme` (override) and `StyleSheetTheme` (default) semantics
+- SkinID must be corrected from `bool` to `string` on `BaseWebFormsComponent` before any implementation
+- Implementation is opt-in via `<ThemeProvider>` wrapper — zero breaking changes to existing consumers
+- Theme resolution logic lives in `BaseWebFormsComponent.OnParametersSet`, benefiting all 50+ components automatically
+- Strategy is exploratory — the README still says themes/skins are not converted; this documents how they *could* be
+
+**Why:** Jeff requested exploration of theme/skin migration despite the project's current exclusion. Developers migrating themed Web Forms apps need guidance. The CascadingValue approach aligns with existing library patterns (TableItemStyle already cascades) and is incrementally adoptable.