Harte Teilnehmer-Obergrenze je Tarif statt automatischem Stufenwechsel

Statt automatisch hochzustufen, blockiert das Anlegen/Reaktivieren
weiterer aktiver Mitglieder, sobald das Limit des gebuchten Tarifs
erreicht ist (Neuanlage, Bearbeiten mit Statuswechsel, Aktivieren-
Button). mitarbeiterverwalten.php zeigt die aktuelle Auslastung an.
Neuer Regressionstest scripts/check-billing-capacity.php deckt alle
drei Enforcement-Stellen ab.

docs/billing.md

@@ -110,9 +110,47 @@ mandant-einstellungen.php (Upgrade-/Portal-Buttons)
   Stripe-Kunde existiert, „Zahlungsmethode verwalten / Abo kündigen"
   (führt zum Customer Portal).
 
-**Noch nicht umgesetzt:** automatischer Stufenwechsel bei wachsender
-Teilnehmerzahl (aktuell muss der Kunde selbst erneut auf „Upgraden"
-klicken, wenn `billing_check_tenant()` einen höheren Bedarf anzeigt).
+**Bewusst nicht umgesetzt:** automatischer Stufenwechsel bei wachsender
+Teilnehmerzahl. Stattdessen gilt eine harte Obergrenze (siehe unten):
+wer mehr aktive Mitglieder braucht, muss selbst upgraden.
+
+## Kapazitätsgrenze je Tarif (umgesetzt)
+
+Statt automatisch hochzustufen, wird die Teilnehmerzahl pro Mandant hart
+auf das Limit des aktuell gebuchten Tarifs begrenzt.
+
+Umgesetzte Dateien:
+
+```text
+app/billing.php (billing_has_capacity_for(), billing_capacity_error_message())
+mitarbeiterverwalten.php (Pruefung vor Anlegen/Aktivieren/Bearbeiten)
+scripts/check-billing-capacity.php (Regressionstest)
+```
+
+- `billing_has_capacity_for($pdo, $tenantId, $additional = 1)`: prüft,
+  ob die aktive Teilnehmerzahl zzgl. `$additional` noch innerhalb des
+  Limits des gebuchten Tarifs liegt (`enterprise` = unbegrenzt).
+- Geprüft an allen drei Stellen, die einen Teilnehmer aktiv anlegen oder
+  reaktivieren können: Neuanlage mit gesetztem „Aktiv"-Haken, Bearbeiten
+  eines bisher inaktiven Mitglieds mit gesetztem Haken, sowie der
+  dedizierte „Aktivieren"-Button. Deaktivieren, reines Bearbeiten ohne
+  Statuswechsel und CSV-Import (bucht nur Zahlungen auf bestehende
+  Mitglieder, legt keine neuen an) sind nicht betroffen.
+- Bei Überschreitung erscheint eine Fehlermeldung mit Tarifname, Limit
+  und Verweis auf Mandant-Einstellungen zum Upgraden; die Aktion wird
+  nicht ausgeführt.
+- `mitarbeiterverwalten.php` zeigt zusätzlich durchgehend „Aktive
+  Mitglieder: X von maximal Y" an, damit das Limit vor dem Anlegen
+  sichtbar ist.
+- Live getestet (`scripts/check-billing-capacity.php`, 10 Assertionen):
+  10. aktives Mitglied bei Cap 10 wird angelegt, 11. wird abgelehnt und
+  landet nicht in der DB, inaktives Anlegen bei vollem Cap funktioniert
+  weiterhin, Aktivieren eines inaktiven Mitglieds bei vollem Cap wird
+  abgelehnt, nach Deaktivieren eines anderen Mitglieds klappt es, und
+  die Reaktivierung über das Bearbeiten-Formular wird ebenso geprüft.
+  Alle bestehenden Tenants lagen zum Zeitpunkt der Umsetzung deutlich
+  unter ihrem Free-Limit (max. 8 von 10 aktiven Teilnehmern), daher keine
+  Auswirkung auf laufenden Betrieb.
 
 ### Live getestet (Testmodus, kein echtes Geld)