Record the naming round in the handoff and LAYOUT.md

Iris PR #19's tip is 2807a92. LAYOUT.md's settled-design section named the
retired `PlaceDescAxis::within`/`shifted`/`sized` constructors and the
`axis`/`axis_mut` accessors; it now says the `_desc` chaining rule, the
`axis` lift, and that every pair is a struct of two per-axis values read
with `[axis]`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/LAYOUT.md

@@ -344,30 +344,41 @@ and `place_at(id, place)` take `impl Into<PlaceDesc>`, so a wrapper that only
 hands over a box passes a `UiRegion` and says nothing else — which is all
 `Pad`, `Offset` and `Painter::widget` do.
 
-`PlaceDescAxis` is one axis, and its three constructors are named after the
-operations the geometry already had, because two of them take the same span
-and differ only in how it is applied:
+`PlaceDescAxis` is one axis. It is built by chaining off the value that says
+it, never by a constructor naming the type, because a constructor makes the
+reader go back to the start of the line. The `_desc` suffix is what says which
+type comes out. The three are named after the operations the geometry already
+had, because two of them take the same span and differ only in how it is
+applied:
 
-- `within(span)` — `UiSpan::within`: composed into the caller's box, so it
+- `UiSpan::within_desc()` — `UiSpan::within`: composed into the caller's box, so it
   moves and scales with it. What an inset speaks.
-- `shifted(span)` — `UiSpan::shift`: window lengths from where the caller's
+- `UiSpan::shifted_desc()` — `UiSpan::shift`: window lengths from where the caller's
   box starts. What a container dividing room speaks, and what makes a moved
   box re-place every child by addition, exactly. Not directional: `Dir::Neg`
   is handled by the span before the numbers get here.
-- `sized(len)` — the body of `placement` with the length given from above
+- `Len::as_desc()` — the body of `placement` with the length given from above
   rather than reported. What a stack's sizing child decides for the rest.
 
 What is optional is a builder, so a caller writes only what it decided:
 `.fills()` says the region is the placement, and `.rel_base(len)` names the
 child's rel base outright. **The rel base a caller does not name follows the
-constructor** — `within` narrows it the way the box is narrowed, `shifted`
-passes it through, `sized` is it. That rule is what makes the common case
+constructor** — `within_desc` narrows it the way the box is narrowed,
+`shifted_desc` passes it through, `as_desc` is it. That rule is what makes the common case
 right by default; stating it by hand was the one thing a container could get
 wrong with nothing failing.
 
-`PlaceDesc` is the pair, with `x` and `y` fields and the `axis`, `axis_mut`
-and `from_axis` of every other pair here, so the joint work — resolving a
+`PlaceDesc` is the pair, with `x` and `y` fields and the `Index<Axis>` and
+`from_axis` of every other pair here, so the joint work — resolving a
 region, reading the fill flags — is written once rather than per axis.
+`PlaceDescAxis::axis(axis)` goes the other way, lifting one axis into a pair
+with the whole box across it.
+
+**Every pair here is a struct of two per-axis values, read with `[axis]`.**
+`impl_axis_index!` gives it `Index<Axis>`/`IndexMut<Axis>`; there are no
+`axis`/`axis_mut` methods and no bare `[T; 2]`. A pair kept as arrays of its
+fields instead — which `LayoutHolds` was, until `AxisHolds` — cannot write
+any of its own operations once.
 
 ## Rel bases, decided boxes and padding