Slider2D: the y-inversion tax on painted backgrounds (y up, CSS down)

Surfaced by the `Slider2D` naming vibe test (#6300). Not a naming problem, and it applies to any two-axis control we ship.

## The problem

`Slider2D` measures `y` **upward** — `yMax` is the top edge — because that is how a value axis reads, and how `Slider`'s vertical orientation already behaves. CSS positions **downward**.

So every consumer who paints something behind the area has to invert by hand:

```tsx
// A CSS background-position, from a Slider2D value
backgroundPosition={`${point.x}% ${100 - point.y}%`}
```

In the naming test, **8/8 agents** across all four arms wrote that inversion themselves on the two prompts that had a painted background (an image focal point, and a saturation/brightness plane). Not one got it wrong — but not one avoided it either, and several called it out as the part they had to reason about. Our own `FocalPoint` story carries the same line.

That is a tax on exactly the use case the component exists for.

## Options

1. **Document it once.** Cheapest. Show the inversion in `Slider2D.doc.mjs` and in the focal-point story, and stop there. Does nothing for an agent that never reads the example.
2. **Offer the CSS-space value.** A second value in the `onChange` payload, or a small exported helper, that hands back `y` already flipped. Adds surface area for arithmetic the consumer can do.
3. **Make the axis direction configurable.** Something like `yDirection: 'up' | 'down'`, defaulting to `'up'`. Honest about the two coordinate systems, but it is a new prop and a new mode, and a wrong setting fails silently and invisibly.

## Recommendation

Not settled — that is why this is an issue rather than a change. Option 1 is the safe default and should happen regardless. Option 2 or 3 need the spec loop, because both add public API for a problem that may be better solved by a sentence.

Worth deciding before the component graduates to core, since 2 and 3 are both harder to add later than now.