Écran Inscriptions : signale quand les types de paiement sont inactifs

Sans identifiants SumUp (code marchand + clé API) ou sans aucun type de
paiement, le formulaire public n'affiche qu'une simple case « cotisation »
et crée le bénévole directement : ni choix du type de paiement, ni étape
d'adresse mécénat, ni paiement en ligne. Rien ne le signalait, si bien
qu'une option « Mécénat » configurée semblait ne pas fonctionner.
L'écran affiche désormais l'état Actif / Inactif sous « Types de
paiement », avec la raison.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -850,6 +850,7 @@ Aucune dépendance locale requise hors Docker.
 | 33    | Cerfa mécénat rempli envoyé en pièce jointe de l'email de confirmation une fois le paiement confirmé (`build_message(attachments=…)`, `app/mecenat/receipts.py`) ; modèle cerfa pré-rempli avec l'association et sa signature | à valider |
 | 34    | Numéro d'ordre unique sur chaque reçu fiscal mécénat (`Volunteer.mecenat_receipt_number`, `202600001`…, migration `0020`), attribué au paiement ou au premier export puis figé | à valider |
 | 35    | Type de paiement à montant libre (`FormPaymentOption.free_amount`, migration `0021`) : case « Montant libre » sur l'écran Inscriptions, montant configuré = minimum, saisie du montant sur le formulaire public (validée côté client et serveur, 10 000 € max) — pensé pour le mécénat | à valider |
+| 36    | Écran Inscriptions : état « Actif / Inactif » des types de paiement (`SumUpStatus`, `FormBuilderPage.tsx`) — sans identifiants SumUp ou sans type de paiement, le formulaire public n'affiche qu'une case « cotisation » (ni choix du type, ni étape mécénat, ni paiement en ligne), ce que rien ne signalait | à valider |
 
 **Reste hors périmètre** (modèle prêt à les accueillir) : SMS, constructeur
 de formulaire, pointage sur site, IA. Frontend : squelette + 6 écrans +