Annulation et remboursement

Ces règles reprennent le comportement du serveur (leaveOuting, cancelSeatBooking, cancelOuting, refundPaymentRecord). Elles ne promettent rien que le code ne fait pas.

• Participant sans paiement confirmé : place annulée, pas de remboursement (rien n’a été capturé).
• Participant avec préautorisation (pending / authorized[_demo]) : l’autorisation est annulée, aucun débit.
• Participant avec paiement capturé (captured[_demo]) : remboursement intégral via le moteur de ledger (DEMO : simulé).
• Déjà partiellement remboursé : le solde capturé restant peut être remboursé, jamais au-delà (over-refund refusé).
• Sortie terminée : on ne quitte plus ; l’historique reste.
• L’organisateur ne peut pas « quitter » sa sortie ; il peut l’annuler.
• Annulation organisateur : la sortie passe à cancelled, les participants sont notifiés, les paiements participants encore ouverts sont annulés (autorisation) ou remboursés (capture) — DEMO.
• Annulation d’une table partenaire (client ou pro du lieu) : même logique d’état de paiement + restitution des places.
• Suppression de compte : les places partenaires actives sont annulées et l’occupation restaurée. Le ledger n’est pas recréé ni soldé automatiquement (conservation légale visée).
• En DEMO : aucun débit réel, aucun virement partenaire réel.
• LIVE n’est pas activé. Une politique consommateur LIVE (frais éventuels, délais) reste À RENSEIGNER avant tout encaissement réel.

Un remboursement n’est jamais recalculé au taux de commission du jour : le ledger conserve applied_fee_percent. Un second remboursement intégral est idempotent ; un montant supérieur au capté restant est refusé.