[Task]: aucune gate ne vérifie le rendu des cartes Open Graph #102

Scope

Ajouter une vérification du rendu des cartes Open Graph (sites/gwm/dist/og/**/*.png, 121 cartes générées par sites/gwm/src/lib/og-card.ts avec satori + sharp) quelque part dans les gates ou la CI. Aucune des quatre gates du CLAUDE.md ne les regarde aujourd'hui : astro check ne voit que le code, et bun run build ne vérifie que la production d'un PNG, pas son contenu.

À trancher dans cette issue, pas avant :

• quoi comparer. Les PNG sont reproductibles à l'octet d'un checkout à l'autre (vérifié sur dev). Mais une montée légitime du moteur de texte bouge des pixels : satori 0.63.2 laisse 1 px d'écart sur le Monaspace Krypton et le letterSpacing. Une comparaison à l'octet contre une référence casserait donc à chaque montée. Pistes : des invariants géométriques (position du filet, présence du pied dans le canvas), ou un écart pixel borné contre la base de la PR ;
• où. Dans bun test, ou dans un job CI qui builde la base et la tête de la PR ;
• le coût. Un build complet de plus si on compare à la base.

Motivation

#97 (satori 0.33.5 → 0.63.2) est passée avec une CI verte alors que le pied de carte sortait du canvas sur les 121 cartes : satori ≥ 0.42 applique content-box par défaut, sans le dire dans ses notes de release (#100, corrigé par #101). La régression n'a été vue que parce que l'analyse des PR Dependabot a comparé dist/og à la main. La prochaine montée de satori, de sharp ou des polices passera par le même trou.

Kind

ci (workflows, déploiement)

Critères d'acceptation

• une montée qui décale la mise en page des cartes OG (cas ⬆️ chore(deps)(deps): Bump satori from 0.33.5 to 0.63.2 #97 sans 🐛 fix(gwm): fige les cartes OG en border-box #101) fait échouer une gate ou la CI
• une montée qui ne bouge que l'anticrénelage du texte ne la fait pas échouer, ou l'écart toléré est documenté
• la vérification est décrite dans CONTRIBUTING.md (section Quality gates)
• bun run check passe (oxlint + bun fmt + astro check)
• bun run build passe
• CHANGELOG mis à jour sous [Unreleased]

Notes / liens

#97, #100, #101. Méthode manuelle utilisée pour l'analyse : builder base et PR dans deux worktrees, cmp carte par carte, magick compare -metric AE pour chiffrer, puis mesurer la position du filet orange (y=191 attendu).