feat(mail): INT-06 E-Mail-Regel-Engine über API steuerbar

mailrules.Store (IMP-03) bekommt Update (bislang nur Create/List/
Delete) — gleiches Muster wie Create: Musterprüfung vor dem Schreiben,
streng auf tenant_slug+id beschränkt, ErrNotFound bei fremder/nicht
existierender ID.

Neues Paket mail/internal/mailrulesapi: vier Endpunkte (GET/POST
/api/v1/mail/rules, PUT/DELETE /api/v1/mail/rules/{id}), tenant-Query-
Parameter Pflicht, gleiche Konvention wie mailapi (INT-01).
Akzeptanzkriterium 3 ist strukturell garantiert: mailrulesapi ruft
ausschließlich mailrules.Store auf, denselben Store, den IMP-03s
Import-Pfad ohnehin verwendet — kein zweiter, paralleler Schreibpfad.

Alle drei Pflichtprüfungen mit echten Nachweisen: vollständiger
Anlegen/Priorisieren/Einsehen/Löschen-Zyklus über echte HTTP-Requests;
eine über die API angelegte Regel wird über genau den Weg gelesen und
ausgewertet, den IMP-03s Import-Pfad geht (Store.List ->
mailrules.NewEngine -> Evaluate) und liefert das korrekte
Klassifizierungsergebnis; Mandant Bs Update-Versuch mit der echten,
bekannten ID von Mandant As Regel liefert 404, Mandant As Regel bleibt
unverändert.

go build/go vet/golangci-lint clean, gesamtes Mail-Modul
regressionsfrei getestet — bestehende mailrules-Tests (IMP-03/IMP-09)
bleiben nach der Update-Erweiterung unverändert grün.

mail/docs/INT-06-PRUEFPROTOKOLL.md

@@ -0,0 +1,82 @@
+# INT-06 — E-Mail-Regel-Engine über API steuerbar: Prüfprotokoll
+
+Datum: 2026-09-01
+Host: 192.168.1.131 (Build/Test/Lint), rsync + ssh
+Pakete: `mail/internal/mailrulesapi` (neu), `mail/internal/mailrules` (erweitert)
+
+## Umsetzung
+
+`mailrules.Store` (IMP-03) hatte bislang nur `Create`/`List`/`Delete` —
+kein `Update`. Ergänzt um `Store.Update(ctx, tenantSlug, id, rule)`
+(gleiches Muster wie `Create`: Musterprüfung vor dem Schreiben, streng
+auf `tenant_slug`+`id` beschränkt, `ErrNotFound` bei fremder/nicht
+existierender ID) — notwendig für Akzeptanzkriterium 1 ("ändern").
+
+Neues Paket `mail/internal/mailrulesapi`: vier Endpunkte
+(`GET`/`POST /api/v1/mail/rules`, `PUT`/`DELETE
+/api/v1/mail/rules/{id}`), `tenant`-Query-Parameter Pflicht, gleiche
+Konvention wie `mailapi` (INT-01). **Akzeptanzkriterium 3
+("API-Änderungen wirken identisch zur bisherigen internen
+Regel-Anwendung") ist strukturell garantiert**: `mailrulesapi` ruft
+ausschließlich `mailrules.Store` auf — denselben Store, den IMP-03s
+Import-Pfad ohnehin verwendet. Es gibt keinen zweiten,
+parallelen Schreibpfad, der abweichen könnte.
+
+## Pflichtprüfung 1: Vertragstest deckt Anlegen/Ändern/Löschen/Priorisieren ab
+
+`TestContract_CreateUpdateDeletePrioritize`: vollständiger Zyklus über
+echte HTTP-Requests — Anlegen (201), Priorität ändern (200, `Priority:
+10 → 1`), Einsehen (Liste zeigt aktualisierten Wert), Löschen (204),
+erneutes Einsehen (leere Liste).
+
+Ergebnis: **BESTANDEN**.
+
+## Pflichtprüfung 2: über API gesetzte Regel wird beim nächsten Import korrekt angewendet
+
+`TestIntegration_RuleSetViaAPIAppliedCorrectlyByEngine`: Regel über
+einen echten HTTP-`POST`-Request angelegt, danach über GENAU DEN WEG
+gelesen und ausgewertet, den IMP-03s Import-Pfad geht
+(`store.List` → `mailrules.NewEngine` → `Evaluate`, unverändertes
+Enginepaket) — die über die API gesetzte Regel liefert das korrekte
+Klassifizierungsergebnis.
+
+Ergebnis: **BESTANDEN**.
+
+## Pflichtprüfung 3: Regeländerung eines Mandanten wirkt nicht auf andere Mandanten
+
+`TestIntegration_RuleChangeIsolatedPerTenant`: Mandant A legt eine
+Regel über die API an; Mandant B sieht sie nicht in seiner Liste;
+Mandant Bs Update-Versuch mit der ECHTEN, bekannten ID von Mandant As
+Regel liefert `404` (nicht etwa eine stillschweigend erfolgreiche
+Übernahme); Mandant As Regel bleibt danach nachweislich unverändert.
+
+Ergebnis: **BESTANDEN**.
+
+## Akzeptanzkriterien
+
+1. **Regeln lassen sich vollständig über die API anlegen, ändern und
+   löschen**: durch Pflichtprüfung 1 belegt.
+2. **Prioritätsreihenfolge ist über die API einsehbar und änderbar**:
+   `priority` ist ein normales Feld von `ruleDTO`, `List` liefert
+   bereits aufsteigend sortiert — durch Pflichtprüfung 1 belegt.
+3. **API-Änderungen wirken identisch zur bisherigen internen
+   Regel-Anwendung**: strukturell durch den gemeinsamen Store
+   garantiert, durch Pflichtprüfung 2 real bewiesen.
+
+## Build/Vet/Lint/Test — Gesamtmodul
+
+```
+go build ./...    → OK
+go vet ./...      → OK
+golangci-lint run ./... → 0 issues
+go test ./... -p 1 (TEST_TENANT_DSN, TEST_MANTICORE_URL, TEST_S3_ENDPOINT/TEST_S3_ACCESS_KEY/TEST_S3_SECRET_KEY gesetzt) → alle Pakete ok, inkl. neuem internal/mailrulesapi
+```
+
+Keine Regression — insbesondere die bestehenden `mailrules`-Tests
+(IMP-03/IMP-09) bleiben nach der `Update`-Erweiterung unverändert grün.
+
+## Ergebnis
+
+INT-06 erfüllt alle Akzeptanzkriterien mit echten, ausgeführten
+Nachweisen. Freigeschaltet: QA-06 (zusammen mit INT-09/INT-10, weiterhin
+extern blockiert).