Discussion: normalized transform-origin ergonomics for declarative transforms

Nobody has claimed this yet.

## Status: discussion / ergonomics

This is not a request for an image-specific API. The question is whether Reactor wants a better **generic** declarative story for normalized transform origin semantics on FrameworkElement-backed controls.

## Background

Reactor already exposes compositor-style transform fluents such as `Rotation`, `Scale`, `Translation`, and `CenterPoint` on elements.

That is enough for fixed-size cases where the center point is known in pixels:

```csharp
Image(icon)
.Width(size)
.Height(size)
.CenterPoint(new Vector3((float)(size / 2), (float)(size / 2), 0f))
.Rotation(angle);
```

So this is **not** "Image cannot rotate declaratively." That part already works.

## The actual ergonomics gap

What Reactor does **not** expose today is the WinUI-style normalized-origin concept behind `FrameworkElement.RenderTransformOrigin`.

In native WinUI, a caller can say "rotate around the element's center" with a size-relative origin like `(0.5, 0.5)` and then apply a transform. In Reactor, the comparable declarative path is pixel-based `CenterPoint`, which means the caller must already know the concrete center in device pixels.

That is workable for fixed-size elements, but awkward when:

- the element size is dynamic or layout-driven
- the desired origin is conceptually normalized (`top-left`, `center`, `bottom-right`, etc.) rather than pixel-based
- callers want to express transform intent declaratively without dropping to `.Set(...)` or recomputing pixel centers manually

## Why I am filing this as a generic discussion

The question is broader than images or icons.

If Reactor wants to improve this area, the abstraction level should be something like:

- a generic transform-origin ergonomic API for FrameworkElement-backed elements, or
- clearer documentation that `Rotation` + `CenterPoint` is the intended Reactor-native pattern and normalized origin is intentionally out of scope

I do **not** think the right direction is an image-only API such as `Image.Rotate(...)`.

## Questions for maintainers

1. Is the intended Reactor guidance simply: use `Rotation` / `Scale` plus explicit pixel `CenterPoint`, even for layout-driven elements?
2. If normalized origin semantics are worth supporting, should that live as a generic element/framework-level API rather than as raw native `RenderTransform` exposure?
3. Does Reactor explicitly want to avoid exposing `RenderTransformOrigin` / `RenderTransform` because that would create two parallel transform systems (native FrameworkElement transforms vs Reactor's current visual/compositor transforms)?

## Smallest plausible upstream direction

If this is worth improving at the package level, the smallest plausible direction seems like one of these:

1. **Docs-only clarification**
- document that `Rotation` + `CenterPoint` is the preferred declarative path
- explain when pixel center is expected vs when `.Set(...)` is an acceptable escape hatch

2. **Generic normalized-origin ergonomics**
- add a generic declarative surface for normalized transform origin semantics
- keep it at the framework element / generic element level, not image-specific
- have it integrate with existing Reactor transform fluents instead of introducing a second transform model

## Non-goals

- not requesting an image-specific fluent
- not requesting a direct wrapper over every native `Transform` subclass
- not suggesting the current fixed-size icon case is blocked; that case can already be handled locally with `CenterPoint` + `Rotation`

Start by reviewing Reactor's existing Rotation, Scale, Translation, and CenterPoint fluent APIs for FrameworkElement-backed controls. Determine whether the intended outcome is documentation clarifying the pixel-based pattern or a generic normalized-origin API that integrates with those fluents. Done requires a maintainer decision on one of those directions and its scope.

Written by the indexing model from the issue text.