ok maintenant il faut dresser une liste exhaustive de toutes les erreurs qui existent dans la page "Confirmation de commande" (/checkout/complete).
Il faut tester chaque fonctionnalité une par une avec le MCP Playwright pour simuler un utilisateur réel.

Comptes de test :

┌───────────┬───────────────────┬──────────────┐
│   Rôle    │       Email       │ Mot de passe │
├───────────┼───────────────────┼──────────────┤
│ admin     │ admin@veza.music  │ Admin123!    │
├───────────┼───────────────────┼──────────────┤
│ creator   │ artist@veza.music │ Artist123!   │
├───────────┼───────────────────┼──────────────┤
│ user      │ user@veza.music   │ User123!     │
├───────────┼───────────────────┼──────────────┤
│ moderator │ mod@veza.music    │ Mod123!      │
├───────────┼───────────────────┼──────────────┤
│ user_new  │ new@veza.music    │ New123!      │
└───────────┴───────────────────┴──────────────┘
Domaine : veza.fr

Comptes à utiliser pour cette page : user, creator

─── INSTRUCTIONS ───

1. AUDIT EXHAUSTIF avec Playwright MCP :

   Pour la page /checkout/complete ("Confirmation de commande"), teste systématiquement :

   a) CHARGEMENT & RENDU
      - La page se charge sans erreur (pas de crash, pas de blank screen)
      - Pas d'erreurs dans la console navigateur (JS errors, failed network requests)
      - Tous les éléments visuels attendus sont présents et visibles
      - Le layout est correct (pas d'overflow, pas d'éléments qui se chevauchent)

   b) FONCTIONNALITÉS SPÉCIFIQUES À CETTE PAGE
  - Message de confirmation
  - Récapitulatif de la commande
  - Liens vers les achats / téléchargements
  - Comportement si accès direct sans commande → redirect

   c) RÉSEAU & API
      - Tous les appels API réussissent (pas de 4xx/5xx inattendus)
      - Les données affichées correspondent aux réponses API
      - Gestion correcte du loading state
      - Gestion correcte des erreurs réseau

   d) SÉCURITÉ
      - Pas de fuite d'informations sensibles (tokens, emails dans l'URL, clés API)
      - Les données d'un autre utilisateur ne sont pas accessibles
      - Les actions protégées nécessitent bien l'authentification
      - CSRF / XSS : vérifier les inputs utilisateur


   e) ACCESSIBILITÉ (a11y)
      - Tous les éléments interactifs ont un accessible name descriptif (pas juste "Checkbox" ou "Button")
      - Les labels sont associés aux inputs
      - Le focus order est logique (Tab navigation)
      - Les aria-labels/aria-describedby sont présents et pertinents
      - Contraste suffisant sur les textes

   f) INTERNATIONALISATION (i18n)
      - Pas de mélange de langues (tout FR ou tout EN, pas les deux)
      - Les traductions sont complètes (pas de clés i18n brutes affichées)

   g) RESPONSIVE
      - Tester en viewport mobile (375px), tablet (768px), desktop (1280px)
      - Pas d'éléments qui débordent
      - Navigation mobile fonctionnelle

2. FORMAT DU RAPPORT :

   Produis un rapport structuré exactement comme suit :

   ```
   Rapport exhaustif des erreurs — Page Confirmation de commande (/checkout/complete)
   Testé avec le(s) compte(s) : user, creator
   Date : [date du test]

   ───
   ERREURS CRITIQUES (bloquantes)

   BUG #1 — [Titre court]
   - Sévérité: CRITIQUE
   - Section: [section de la page]
   - Repro: [étapes de reproduction]
   - Erreur: [description technique]
   - Source: [fichier:ligne si identifiable]
   - Impact: [impact utilisateur]

   ───
   ERREURS HAUTES

   ...

   ───
   ERREURS MOYENNES

   ...

   ───
   ERREURS FAIBLES

   ...

   ───
   RÉSUMÉ

   ┌────────────────────────────┬─────────┬──────────────┐
   │         Catégorie          │ Nombre  │ Sévérité max │
   ├────────────────────────────┼─────────┼──────────────┤
   │ ...                        │ ...     │ ...          │
   └────────────────────────────┴─────────┴──────────────┘
   ```

3. CORRECTION DES BUGS :

   Après avoir dressé la liste, corrige TOUS les problèmes trouvés pour que la page soit
   entièrement fonctionnelle. Pour chaque fix :
   - Identifie le fichier source exact
   - Applique le correctif
   - Vérifie avec Playwright que le bug est résolu

4. TRANSFORMATION EN TESTS E2E :

   Transforme toute la suite de vérification que tu viens de faire pour la page /checkout/complete en suite de
   tests Playwright que tu peux ajouter directement à ceux existants dans veza-e2e/.

   Spécifications des tests :
   - Fichier : veza-e2e/tests/checkout-complete.spec.ts
   - Framework : Playwright Test (@playwright/test)
   - Pattern : Page Object Model si la page est complexe
   - Chaque bug trouvé ET corrigé = au moins 1 test de non-régression
   - Chaque fonctionnalité testée manuellement = 1 test automatisé
   - Tests organisés par describe() : "Chargement", "Fonctionnalités", "Sécurité", "a11y", "i18n"
   - Les tests doivent être indépendants (setup/teardown propre)
   - Utiliser les test accounts définis ci-dessus pour l'auth dans les fixtures

   Structure attendue :
   ```typescript
   import { test, expect } from '@playwright/test';

   test.describe('Confirmation de commande (/checkout/complete)', () => {
     test.describe('Chargement & Rendu', () => {
       test('la page se charge sans erreur', async ({ page }) => {
         // ...
       });
     });

     test.describe('Fonctionnalités', () => {
       // Un test par fonctionnalité
     });

     test.describe('Sécurité', () => {
       // Tests de sécurité
     });

     test.describe('Accessibilité', () => {
       // Tests a11y
     });

     test.describe('Régression', () => {
       // Un test par bug corrigé
     });
   });
   ```

   Assure-toi que les nouveaux tests s'intègrent avec la config Playwright existante
   et ne dupliquent pas des tests déjà présents.