Implémentation de `agtc-card`

---

Contexte

agtc-card est un conteneur visuel pour regrouper des informations liées. C'est l'un des composants les plus utilisés dans les interfaces — il structure les tableaux de bord, les listes de résultats, les formulaires groupés.

Deux questions ont guidé les décisions :

1. Interactivité — une carte peut être cliquable (lien vers un détail) ou purement contenante. Faut-il encoder ce comportement dans le composant ?

2. Sections — header, body, footer sont des patterns récurrents. Faut-il les imposer structurellement ou les laisser libres via slots ?

---

Décisions

Décision 1 — Pas d'interactivité native dans v1

Une carte cliquable est un pattern d'accessibilité complexe : l'élément interactif doit être <a> ou <button>, pas un <div> avec onclick.

Décision : agtc-card est non interactif. Pour une carte cliquable, le consommateur place un <a> ou <agtc-button> à l'intérieur. Un composant agtc-card-link pourrait être ajouté en v2 si le besoin est récurrent.

Alternative rejetée : ajouter un attribut clickable avec tabindex="0" et role="button" — rejeté car un <div role="button"> sans <button> natif est un anti-pattern WCAG 4.1.2 (les éléments interactifs doivent utiliser des éléments HTML sémantiques).

---

Décision 2 — Slots nommés header / footer avec séparateurs automatiques

Les slots header et footer sont détectés via slotchange + assignedNodes(). Les séparateurs (border) n'apparaissent que si le slot est réellement utilisé — évite un border orphelin sur une card sans header.

Le padding des sections header/body/footer est uniforme (même valeur que l'attribut padding) pour que l'espacement soit cohérent visuellement.

Exception : has-header et has-footer suppriment le padding-top du body quand un header est présent, et le padding-bottom quand un footer est présent — évite le double espacement aux jointures.

---

Décision 3 — 3 variantes : default / elevated / flat