Design declarative Brush and Font specs to avoid WinRT object construction in render

Problem

Reactor render bodies can currently force authors to construct relatively expensive WinRT objects directly, especially for things like brushes and fonts.

Examples of the shape we should think through:

• Brush values often require constructing WinRT objects such as SolidColorBrush.
• Font-related values can also involve non-trivial WinRT objects or lookups.
• This is different from simple WinRT structs like Thickness, which are cheap value types and feel fine to construct inline in render.

In a React-like render model, render bodies should stay cheap and declarative. If authors repeatedly create brushes/fonts during render, we risk unnecessary allocation and object churn, but caching every realized WinRT object forever could leak an unbounded number of brush/font instances.

Design questions

This needs design, not a slam-dunk implementation:

• What is the right declarative model for a "brush spec" or "font spec" that feels natural in Reactor/React-style UI?
• Should specs be immutable records/value types that Reactor realizes to WinRT objects during reconciliation?
• Which objects are safe and useful to cache, especially for non-animated/static values?
• What cache lifetime model avoids leaking every brush/font ever requested? Do we need an expiring cache, weak cache, theme-aware cache, or per-host cache?
• How should theme resources, high contrast, dynamic system brushes, and animated brushes interact with any cache/spec model?
• How do we preserve escape hatches for callers that really do need to provide a concrete WinRT Brush or font object?

Expected outcome

Investigate and design an API/model that lets authors express brush and font intent declaratively without constructing expensive WinRT objects in render bodies, while avoiding unbounded object retention and preserving correct behavior for theme/dynamic/animated cases.

Begin by reviewing the current Reactor render path and how Brush and font values are represented; the issue does not name specific files or tests. Define a declarative API/model, cache-lifetime behavior for static and dynamic cases, and an escape hatch for concrete WinRT objects. Done means the design addresses theme, high-contrast, animated, and retention concerns.