LIC-03: nutzungszaehler-quotas

internal/usage: Store.Increment aktualisiert Zaehlerstaende ueber ein
einziges atomares SQL-UPSERT (value = value + delta) statt Read-Modify-Write
in Go — haelt Zaehlerstaende bei parallelen Schreibzugriffen konsistent
(Akzeptanzkriterium 1), ganz ohne Anwendungs-Lock. Quotas sind Konfiguration
(usage_quotas-Tabelle je Tenant+Metrik), kein Hardcode.

Check/Enforce leiten aus Zaehlerstand + Quota eine definierte Reaktion ab
(StatusOK/Warning bei 80%/Exceeded, Akzeptanzkriterium 2) — Enforce ruft eine
uebergebene Reaction-Funktion auf, wenn der Status nicht OK ist; die
konkrete Sperr-/Benachrichtigungslogik bleibt beim Aufrufer (z.B. TEN-02 vor
Benutzeranlage), Enforce garantiert nur zuverlaessiges Ausloesen. Fehlende
Quota-Konfiguration bedeutet unbegrenzt (StatusOK), kein Fehler.

RunPeriodicAggregation ist das Aggregations-Grundgerüst (Akzeptanzkriterium 1:
"periodisch aggregiert") — dieselbe In-Prozess-Worker-Goroutine-Konvention
wie internal/tenant.Lifecycle.RunSweeper. Die konkrete Aggregationsquelle
(Zeilen zaehlen in Modul-Tabellen) haengt vom jeweiligen Modul ab und ist
nicht Teil dieser Kachel.

Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Quota-Ueberschreitung automatisiert erkannt, definierte Reaktion
   ausgeloest — TestEnforce_TriggersReactionOnExceeded: Reaction-Callback
   wird mit StatusExceeded aufgerufen. PASS.
2. Aggregationsjob liefert bei parallelen Schreibzugriffen konsistente
   Zaehlerstaende — TestIncrement_ConsistentUnderConcurrentWrites: 50
   nebenlaeufige Increments, Endstand exakt 50 (kein Lost Update). PASS.
3. Zaehlerstand eines Tenants beeinflusst nicht den eines anderen —
   TestIncrement_IsolatedBetweenTenants. PASS.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

internal/usage/aggregation.go

@@ -0,0 +1,32 @@
+package usage
+
+import (
+	"context"
+	"log/slog"
+	"time"
+)
+
+// AggregateFunc berechnet/aktualisiert Zaehlerstaende aus einer autoritativen
+// Quelle (z.B. "zaehle Zeilen in einer Modul-Tabelle") — die konkrete Quelle
+// haengt vom jeweiligen Modul ab und ist nicht Teil dieser Kachel. Das
+// Aggregations-Grundgerüst selbst (periodischer Trigger) ist es.
+type AggregateFunc func(ctx context.Context) error
+
+// RunPeriodicAggregation ruft aggregate in festen Abstaenden auf, bis ctx
+// beendet wird — dieselbe In-Prozess-Worker-Goroutine-Konvention wie
+// internal/tenant.Lifecycle.RunSweeper (Akzeptanzkriterium 1: "periodisch
+// aggregiert").
+func RunPeriodicAggregation(ctx context.Context, interval time.Duration, aggregate AggregateFunc) {
+	ticker := time.NewTicker(interval)
+	defer ticker.Stop()
+	for {
+		select {
+		case <-ctx.Done():
+			return
+		case <-ticker.C:
+			if err := aggregate(ctx); err != nil {
+				slog.Error("nutzungszaehler-aggregation fehlgeschlagen", "error", err)
+			}
+		}
+	}
+}