capitalisation: triage 95_a_capitaliser + création domaine infra

Triage des 27 propositions du buffer de capitalisation (skill
capitalisation-triage), avec vérification des doublons contre la base.

Intégré dans knowledge/ (23 entrées):
- backend: redis (compensation incrBy non-atomique), nestjs (injection
  cassée sous tsx watch; guard write mode dégradé), async (test rollback
  pipeline multi-fichiers), contracts (idempotence POST), auth (disclosure
  comptes soft-deleted), prisma (index partial soft-delete), llm-providers
  (nouveau: OAuth vs API key, prompt caching).
- frontend: tests (garde-fous parking Later), navigation (fichiers
  non-route sous src/app Expo Router), general (type client vs payload
  backend), state (fallback catch-all mapping DB→UI).
- workflow: story-tracking (statut BMAD vs narratif obsolète).
- product: general (nouveau: doc feature store sans UI).
- infra: NOUVEAU DOMAINE (traefik, tailscale, docker, docker-networking,
  reverse-proxy-paths, sidecar tailscale) + 00_INDEX.md.

Autres:
- 90_debug_et_postmortem.md: post-mortem réseau Docker partagé hors compose.
- Rejeté 3 doublons (types enum contracts, getter PrismaService, $transaction).
- Buffer 95_a_capitaliser.md purgé et restauré à son état initial.
- _projects.conf: MAJ statuts epics + ajout app-rl799.

knowledge/frontend/risques/general.md

@@ -790,3 +790,32 @@ Garder `<fieldset>/<legend>` uniquement quand on accepte le rendu natif (groupe
 - Contexte technique : HTML / a11y / CSS — RL799_V2 02-05-2026
 
 ---
+
+<a id="risque-type-client-non-maj-extension-payload-backend"></a>
+## Type client non mis à jour lors d'une extension de payload backend
+
+### Risques
+
+- Quand un nouveau champ est ajouté dans un objet retourné par une Server Action, le type TS côté client n'est pas toujours mis à jour en parallèle
+- Si le retour de la Server Action est casté vers un type plus étroit, TypeScript accepte l'incompatibilité **silencieusement** : le champ existe au runtime mais reste invisible pour les consommateurs TS
+
+### Symptômes
+
+- Le payload contient un champ supplémentaire en runtime, mais le type client ne l'expose pas
+- Une tâche "mettre à jour le test si le payload expose le nouveau champ" est marquée done en vérifiant le test, sans vérifier le type source qui l'alimente
+- Aucune erreur de compile car le cast masque la divergence
+
+### Bonnes pratiques / mitigations
+
+Pour toute extension d'un payload backend (ajout de champ), appliquer une **checklist de propagation** :
+
+1. Le type TS côté client (ex : type d'item média, type de l'entité)
+2. Le contrat Zod si présent
+3. Les fixtures de test qui typent le payload
+4. Les composants qui déstructurent le payload (vérifier les accès au nouveau champ manquants)
+
+- Règle : ne pas laisser cette propagation à la décision implicite du dev — l'expliciter comme checklist dans la story / la PR.
+
+- Contexte technique : Next.js / Server Actions / TypeScript / Zod — app-template-resto 25-06-2026
+
+---