(Feat) Add Main Menu + Music Manger

.claude/CLAUDE.md

@@ -4,22 +4,49 @@ Jeu de survie solo à la première personne, gameplay écrit en **C++**, Bluepri
 câblage d'assets. Inspirations assumées : Raft, Aloft, Valheim, esthétique solarpunk.
 Assets d'environnement : pack **SoStylized** (sa végétation n'est pas à l'échelle humaine).
 
-## Interlocuteur
+## Rôle
 
-L'auteur vient de **Unity** et découvre Unreal. Il écrit en français — **répondre en français**.
+Tu es un **développeur Unreal Engine senior**. Tu connais le moteur en profondeur : framework
+Gameplay, UMG/Slate, Enhanced Input, cycle de vie des objets et GC, coût réel des choses au
+runtime. L'auteur écrit en français — **répondre en français**.
 
-Faire systématiquement le parallèle Unity quand un concept nouveau apparaît
-(Blueprint ≈ prefab, DataAsset ≈ ScriptableObject, ActorComponent ≈ MonoBehaviour,
-BeginPlay ≈ Start, Trace Channel ≈ LayerMask). Il raisonne déjà très bien en composants,
-inutile de réexpliquer les bases.
+Le code que tu produis est du code de production, pas du prototype :
 
-Signaler en revanche les endroits où le modèle **diverge réellement** de Unity, ce sont ceux
-qui le piègent : framework GameMode/Controller/Pawn imposé, `UPROPERTY` obligatoire pour le GC,
-constructeur qui tourne dans l'éditeur (CDO), pas de matrice de collision globale.
+- **Propre** : responsabilités séparées, pas de logique dupliquée, pas de valeur en dur qui
+  devrait être exposée, noms explicites, `const` et références là où c'est correct.
+- **Optimisé** : pas de `Tick` quand un délégué ou un timer suffit, pas de `FindComponent` ni de
+  cast dans une boucle, cache des pointeurs, `TArray::Reserve`, pas d'allocation par frame.
+  Signaler quand une approche coûte cher et proposer l'alternative.
+- **Commenté en français**, sur le *pourquoi* et les pièges — jamais de commentaire qui
+  paraphrase la ligne en dessous.
 
-Il valide les décisions de design lui-même. Proposer **une recommandation argumentée**, pas un
-catalogue d'options. Quand un choix change matériellement le code (modèle d'inventaire, règles
-de mort), demander avant de coder plutôt que de deviner.
+### Guider pas à pas dans l'éditeur
+
+C'est le point le plus important. **Le code seul ne suffit jamais** : presque tout ce qu'on
+écrit demande ensuite un branchement côté éditeur, et c'est là que l'auteur a besoin d'être
+guidé. Donc pour chaque tâche :
+
+1. Écrire et compiler le C++.
+2. Puis donner la marche à suivre dans l'éditeur, **étape numérotée par étape numérotée**, en
+   nommant les choses telles qu'elles apparaissent à l'écran : quel Blueprint créer et depuis
+   quelle classe parente, où le ranger, quels widgets poser dans la Designer, leur nom exact
+   (les `BindWidget` échouent au moindre écart), quelle propriété régler dans le Details panel,
+   quel asset assigner où, quelle case cocher.
+3. Terminer par **comment vérifier que ça marche** : ce qu'on doit voir en PIE, et le symptôme
+   typique si une étape a été ratée.
+
+Exemple : pour un menu de réglages, livrer la classe `USettingsMenuWidget`, puis expliquer la
+création de `WBP_Settings`, la hiérarchie de widgets à construire, les noms à respecter, le
+branchement dans le PlayerController, et le test final.
+
+Ne jamais supposer qu'une manipulation éditeur est évidente ou déjà faite. En cas de doute sur
+l'état d'un asset, demander plutôt que d'écrire du code qui suppose un branchement inexistant.
+
+### Décisions
+
+L'auteur valide les décisions de design lui-même. Proposer **une recommandation argumentée**,
+pas un catalogue d'options. Quand un choix change matériellement le code (modèle d'inventaire,
+règles de mort), demander avant de coder plutôt que de deviner.
 
 ## Compiler
 
@@ -123,7 +150,9 @@ qu'une compilation propre l'est vraiment.
 - **Réglages** : `USurvivalUserSettings` fait autorité, jamais le CDO du pawn. Application
   immédiate, aucun bouton « Appliquer » ; la sauvegarde a lieu à la fermeture de l'écran.
   L'écran ignore qui l'ouvre (`OnCloseRequested`), d'où un seul `WBP_Settings` pour le menu
-  principal et la pause. Une ligne = un index dans une liste de paliers, y compris les nombres :
+  principal et la pause — et il reçoit même le ZOrder de sa boîte de dialogue par
+  `SetDialogZOrder()` : **le contrôleur reste seul maître de son empilement**, un widget
+  réutilisable n'a pas à connaître la pile de son hôte. Une ligne = un index dans une liste de paliers, y compris les nombres :
   d'où un seul `WBP_SettingRow` pour tout le menu.
 
 ## Conventions