docs(direction): la excepcion que el usuario veto — :dir() que traduce una prop logica

«NO añadas la direccion al avatar porque tambien depende de donde se situa el
badge». Tiene razon, y mi regla de §2 —«si el recipe usa :dir(), acepta y estampa
`dir`»— es demasiado ancha: mandaba al siguiente a hacer justo eso.

NO toda regla `:dir()` afirma una direccion. `Avatar.Badge` expone la esquina con
`position` en terminos LOGICOS (`top-start` / `top-end`), asi que el ancla
(`inset-inline-*`) ya se voltea sola; `:dir(rtl)` solo invierte el SIGNO del
`translate` fisico que hace sobresalir la insignia —por eso las cuatro reglas
llevan su marcador `rtl-physical:`, es el caso sancionado de RTL-1, no un
selector de lado—. `Image` es lo mismo con otro mecanismo: `object-position` no
tiene palabra clave logica, asi que `:dir(rtl)` traduce a `left`/`right` el
`start`/`end` que el consumidor ya eligio.

En los dos, una prop `dir` seria un SEGUNDO mando para lo que el primero ya
decide, y pelearia en vez de componer: el ancla logica resuelve por la direccion
ambiente mientras la prop dice fijarla. Esa regla `:dir()` necesita la direccion
que REALMENTE maqueto el elemento, que es la heredada, por diseño y no por
descuido.

El test que queda escrito: si el componente tiene vocabulario logico propio para
el eje, no lleva `dir`. Un `Switch` no lo tiene —su pulgar viaja en un sentido y
la direccion es el unico input—, asi que ahi si es significativo. Un
`Avatar.Badge` tiene `position`, asi que no.

Barrido: de los 13 recipes con `:dir()`, SOLO `avatar` e `image` tienen ademas
prop logica start/end. La excepcion son exactamente esos dos.

Corrige tambien lo que reporte como hallazgo: «avatar e image usan `:dir()` sin
aceptar `dir`» NO es un defecto ni una decision pendiente, es el diseño correcto.

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

docs/canon/direction-contract.md

@@ -136,6 +136,26 @@ The inverse is also true — a component whose direction-dependence is purely
 JavaScript does not need the attribute, and adding it only enlarges the DOM.
 **Ask who reads the direction**, then stamp accordingly.
 
+### The exception: `:dir()` translating an already-logical prop
+
+Not every `:dir()` rule is about asserting a direction. Some components expose
+the axis themselves, as a **logical prop** — a badge at `top-start` or
+`top-end`, an image anchored at `start` or `end`. There the consumer has already
+said which side they mean, in logical terms; `:dir()` is only supplying the
+physical form CSS lacks: the sign of a `translate`, or `object-position: left`
+where no `object-position: start` exists.
+
+**Those components must NOT take a `dir` prop.** It would be a second knob for
+an outcome the first knob already decides, and the two would fight rather than
+compose — the logical anchor resolves from the ambient direction while the prop
+claims to set it. The `:dir()` rule needs the direction that actually laid the
+element out, which is the inherited one, by design and not by omission.
+
+The test is whether the component has its own logical vocabulary for the axis.
+A `Switch` has none — its thumb travels one way and direction is the only input,
+so asserting `dir` on it is meaningful. An `Avatar.Badge` has `position`, so it
+is not.
+
 ---
 
 ## 3. Selector doctrine