Sélection rapide d'équipement, mort par chute, fixes inventaire/audio

- Ajoute le menu de sélection rapide (WB_QuickSelect, IA_QuickSelectAGIS/IA_QuickEquipAGIS)
  et l'écran de mort (WB_YouDied) sur Inventory_Player.
- Corrige le mauvais placement des items dans les slots d'équipement (désalignement
  entre PlayerInventoryPart1/2 et les widgets d'équip slot).
- Corrige le bourdonnement audio permanent causé par une double instance de
  Ultra_Dynamic_Weather créée en PIE.
- Renomme Systems/Blueprints/d/SandboxCharacter_CMC_ABP vers son bon dossier.
- Met à jour Architecture_Projet.md et ajoute le skill de maintenance associé.
- Inclut le fix de config audio (DefaultEngine.ini) et les changements de config
  moteur associés.

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

.claude/skills/maintain-architecture-doc/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: maintain-architecture-doc
+description: Maintient Architecture_Projet.md (documentation de référence de l'architecture du projet ProjectF) synchronisé avec la structure réelle du projet. À utiliser avant et après toute création, suppression, déplacement ou renommage de fichier/dossier, ou toute évolution significative d'un système de gameplay.
+---
+
+# Maintenir `Architecture_Projet.md`
+
+## Rôle de ce document
+
+`Architecture_Projet.md` (à la racine du projet) est la **documentation de référence de l'architecture complète du projet ProjectF**, écrite en priorité pour des modèles d'IA. Il décrit l'arborescence complète du projet, le rôle de chaque dossier/fichier important, les dépendances entre systèmes et les conventions à respecter.
+
+**Ce document n'a de valeur que s'il reste synchronisé avec l'état réel du projet.** Un `Architecture_Projet.md` obsolète est pire qu'utile : il fait perdre du temps et induit en erreur les futures sessions d'IA qui lui font confiance.
+
+## Quand utiliser ce skill
+
+Utilise ce skill (consultation et/ou mise à jour) dans les cas suivants :
+
+1. **Avant** de modifier la structure du projet de façon un peu conséquente (créer un nouveau système, réorganiser un dossier, migrer des assets) : lis `Architecture_Projet.md` pour comprendre où les choses vivent actuellement et où ton changement doit s'insérer, en cohérence avec les conventions déjà en place (voir §1.4/§1.5 du document).
+2. **Après** toute action qui change la structure du projet, notamment :
+   - création d'un fichier ou dossier important (Blueprint, Widget, DataAsset, Struct, Enum, Input Action, système de gameplay…) ;
+   - suppression d'un fichier ou dossier documenté ;
+   - déplacement d'un fichier ou dossier documenté ;
+   - renommage d'un fichier ou dossier documenté ;
+   - évolution suffisamment importante d'un système existant (nouvelle responsabilité, nouveau fichier central, changement de dépendances entre systèmes).
+3. Quand tu n'es pas sûr de savoir où se trouve un système ou un type de fichier avant de commencer une tâche — consulte le document plutôt que d'explorer le projet à l'aveugle.
+
+Pour une petite modification purement interne à un Blueprint déjà documenté (ajouter une fonction, une variable, corriger un bug de logique) qui ne change ni son rôle général ni l'arborescence, une mise à jour du document n'est en général PAS nécessaire — sauf si la description existante du fichier devient trompeuse.
+
+## Comment mettre à jour le document
+
+1. **Localise la bonne section.** Le document est organisé par grande zone (`§3 Content/Core/`, `§4 Content/Systems/`, `§5 Content/Data/`, `§6 Content/UI/`, `§7 Items/PCG/Maps/VFX/Prop`, `§8 assets tiers`). Trouve la section correspondant au dossier concerné avant d'éditer — ne duplique pas une entrée dans plusieurs sections.
+
+2. **Fichier créé** → ajoute une ligne dans l'arborescence du dossier concerné, avec une description courte (une phrase, orientée "à quoi ça sert" / "quel rôle" — pas une paraphrase du nom de fichier). Suis le format déjà utilisé :
+   ```text
+   ├── NomDuFichier.uasset       → Rôle en une phrase.
+   ```
+   Si le fichier crée un nouveau sous-système notable, ajoute-le aussi à la vue de dépendances (§1.3) si pertinent.
+
+3. **Fichier/dossier supprimé** → retire entièrement son entrée. Ne laisse jamais une ligne qui référence un chemin qui n'existe plus. Si sa suppression change une dépendance décrite en §1.3, corrige aussi cette section.
+
+4. **Fichier/dossier déplacé ou renommé** → corrige le chemin (et le nom) à l'endroit où il apparaît. S'il change de section logique (ex. un Blueprint qui quitte `Systems/Inventory/` pour un nouveau dossier `Systems/Crafting/`), déplace aussi son entrée dans la bonne section du document, pas seulement son chemin.
+
+5. **Nouveau système de gameplay** (nouveau dossier sous `Content/Systems/<Nom>/` ou équivalent) → crée une nouvelle sous-section dans `§4` (ou une nouvelle section de premier niveau si le système est majeur), avec :
+   - la liste de ses fichiers importants et leur rôle ;
+   - ses dépendances avec les autres systèmes, ajoutées à `§1.3` si le système interagit avec l'inventaire, les stats, ou le personnage.
+
+6. **Évolution significative d'un système existant** → mets à jour sa description pour refléter son rôle actuel. Ne laisse pas une description qui décrit un comportement qui n'existe plus.
+
+7. **Nouveau dossier d'assets tiers volumineux** (Marketplace, Fab, packs d'animation…) → ajoute-le en `§8` avec une description sommaire d'une ligne, SANS lister ses fichiers individuellement (voir règle de détail ci-dessous).
+
+## Règle de niveau de détail
+
+- Un fichier "important" à documenter individuellement = il porte de la **logique ou des données de gameplay** propres au projet (Blueprint, Widget, ActorComponent, DataAsset, Struct, Enum, Input Action, GameMode/PlayerController, système PCG…).
+- Un fichier purement artistique (texture, mesh, clip d'animation individuel, matériau de variante, miniature) n'a **pas** besoin d'entrée dédiée : il suffit que son dossier parent soit listé et décrit brièvement. Ne gonfle pas le document en énumérant chaque texture d'un pack d'assets.
+- Un dossier d'assets tiers volumineux (Marketplace, Megascans, packs de mocap) est décrit en une ligne (`§8`), pas détaillé fichier par fichier.
+
+## Vérification de cohérence
+
+Avant de terminer une tâche qui a touché à la structure du projet, vérifie que :
+
+- chaque chemin mentionné dans `Architecture_Projet.md` correspondant à ta zone de travail existe toujours réellement (pas de faux positif après un déplacement/renommage que tu aurais oublié de répercuter) ;
+- les nouveaux fichiers importants que tu as créés apparaissent bien dans le document, avec une description ;
+- les fichiers que tu as supprimés n'apparaissent plus nulle part dans le document (y compris dans `§1.3` Dépendances et dans les tableaux de conventions si applicable) ;
+- si tu as un doute sur l'exhaustivité, un simple `find <dossier> -type f` (ou `Glob`) suffit à comparer rapidement la réalité du dossier concerné avec ce que le document décrit — inutile de ré-auditer tout le projet à chaque fois, seulement la zone que tu viens de modifier.
+
+## Ce qu'il ne faut jamais faire
+
+- Ne jamais terminer une tâche qui a modifié la structure du projet (création/suppression/déplacement/renommage de fichier ou dossier important, nouveau système) sans avoir mis à jour `Architecture_Projet.md` en conséquence.
+- Ne jamais laisser une description qui ne correspond plus à la réalité "parce que ce n'est pas grave" — un document d'architecture légèrement faux est plus dangereux qu'un document incomplet mais honnête.
+- Ne jamais dupliquer une entrée dans deux sections différentes du document après un déplacement (supprime l'ancienne en ajoutant la nouvelle).