# Etiquetas de parentesco en perfiles principales

## Objetivo

Mostrar el parentesco del contacto público desde la perspectiva correcta y nunca exponer códigos canónicos como `SON_OR_DAUGHTER` en la ficha web.

## Regla de perspectiva

- Cuando `is_primary === true`, el parentesco se presenta de forma directa.
- Cuando `is_primary !== true`, se conserva la conversión a la relación inversa usada actualmente.
- La decisión depende exclusivamente de `is_primary`; `care_type` no participa.

Ejemplos en español:

| Valor recibido | Perfil principal | Perfil no principal |
|---|---|---|
| `FATHER` | Padre | Hijo/hija |
| `SON_OR_DAUGHTER` | Hijo/hija | Padre/madre |

## Adaptación del catálogo

La API devuelve el catálogo bajo el sobre `{"data":[...]}`. `PersonProfileRepository` debe extraer esa lista antes de entregarla a `FamilyRelationshipLabelResolver`. El resolver seguirá aceptando la forma plana utilizada por pruebas y posibles respuestas heredadas.

## Localización y degradación

- Los códigos conocidos se resuelven mediante el catálogo localizado.
- En español, `SON_OR_DAUGHTER` se muestra como `Hijo/hija`; en inglés, como `Son or daughter`.
- Un código desconocido podrá conservarse como texto legible, pero nunca se alterará la perspectiva sin una equivalencia conocida.

## Alcance

El cambio se limita a `web_mycode`. No modifica datos persistidos, contratos de la API ni aplicaciones móviles.

## Pruebas

Se agregará cobertura de regresión para:

1. La forma real del catálogo `{"data":[...]}`.
2. Relación directa con `is_primary === true`.
3. Relación inversa con `is_primary === false`.
4. Etiquetas localizadas sin exposición de claves canónicas.

La validación final ejecutará `php artisan architecture:audit --strict` y `php artisan test`.