Optimierung 2.6: reprocessAfterContentChange im PressReleaseService

Den 3x identischen contentChanged->fresh->reclassifyIfClassified->
rescoreIfScored-Block (admin/edit 1x, customer/edit 2x) in
PressReleaseService::reprocessAfterContentChange() zentralisiert.

Hinweis: Eine vollstaendige createDraft()/updateContent()-Verlagerung
wurde bewusst NICHT erzwungen — die Attributsaetze und der umgebende
Validierungs-/Fehlerfluss von Admin (no_export, direkter review-Status)
und Customer (placeholder_variant, Titel-Fallback, immer Draft) divergieren
real; eine gemeinsame Persistenzmethode waere fragil bei grosser Testflaeche.

Tests: 2 neue Faelle; volle Suite gruen (796 passed, 1 skipped).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

app/Services/PressRelease/PressReleaseService.php

@@ -106,6 +106,24 @@ class PressReleaseService
         ScorePressRelease::dispatch($pressRelease->id)->onQueue('classification');
     }
 
+    /**
+     * Nach einer inhaltlichen Änderung (Titel/Text) einer bereits geprüften
+     * bzw. bewerteten PM erneut prüfen (Re-Check ohne Routing) und neu
+     * bewerten. Operiert auf dem frischen Modellstand. Single Source of Truth
+     * für die vier PM-Editoren.
+     */
+    public function reprocessAfterContentChange(PressRelease $pressRelease): void
+    {
+        $fresh = $pressRelease->fresh();
+
+        if ($fresh === null) {
+            return;
+        }
+
+        $this->reclassifyIfClassified($fresh);
+        $this->rescoreIfScored($fresh);
+    }
+
     /**
      * Routet eine frisch klassifizierte PM anhand des KI-Ergebnisses
      * (Decision-Update §5.0, Entscheidung 12.06.2026). Wird vom