companies: Adress-Klassifizierung persistieren (Roadmap 1a.2, E1 = 3)

Die Klassifizierung aus dem Trockenlauf wird jetzt nach company_email_groups
geschrieben — eine Zeile je Adresse, denn ob zusammengeführt werden darf, ist
eine Eigenschaft der Adresse und nicht der Firma. Die Zusammenführung (1a.3)
und die laufende Zuordnung neuer API-Meldungen (1a.4) lesen dort, statt den
Trockenlauf jedes Mal neu zu rechnen.

Die Logik liegt jetzt in CompanyAddressClassifier und wird von Bericht und
Persistierung gleichermaßen benutzt. Beide müssen dieselbe Antwort geben —
sonst zeigt der Bericht etwas anderes, als die Zusammenführung später tut.

manual_classification übersteuert die berechnete Klasse und überlebt jede
Neuberechnung. Nötig für Grenzfälle, die nur ein Mensch entscheiden kann:
presse@pr4you.de ist eine echte Agentur, sieht in den Daten aber aus wie eine
Wegwerfadresse. effectiveClassification() ist die einzige Stelle, die
Abnehmer fragen dürfen.

Eigene Tabelle statt Spalten auf companies: Die Tabelle trägt einen
FULLTEXT-Index, jedes ADD COLUMN dort ist ein Rebuild. Die Zuordnung Firma →
Gruppe ist ohnehin nur die normalisierte Adresse, und die eine Stelle, die
festlegt, was "dieselbe Adresse" heißt, ist jetzt Company::emailKey().

E1 ist entschieden: Schwellwert 3, nach drei Live-Läufen. Bei 2 wird jede
zweite Schreibweise zur "Agentur", bei 4 wandern echte Mehrkunden-Adressen in
die Handarbeit. Konfiguriert in config/newsroom.php; Bericht und
Klassifizierung lesen den Wert von dort.

Die Ähnlichkeitsprüfung ist quadratisch und jetzt bei 25 Repräsentanten
gedeckelt — ab da steht die Klasse fest, und yahoo@yahoo.com mit über 4000
Namen hätte sonst neun Millionen Levenshtein-Aufrufe gekostet. Laufzeit über
den ganzen Bestand: 25 s → 3 s, Ergebnis unverändert.

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

dev/2026-09-01/roadmap-2026.md

@@ -227,8 +227,8 @@ Braucht Betreuungszeit und ist teilweise von Dritten abhängig.
 
 | Nr. | Frage | Betrifft |
 |---|---|---|
-| E1 | Schwellwert, ab wie vielen abweichenden Firmennamen eine Adresse als Sammeladresse gilt | 1a.2 |
-| E2 | Zeigt die Absenderansicht Rohzahlen oder Einordnung gegen den Portaldurchschnitt | 1c.1 |
+| ~~E1~~ | **Entschieden 11.09.2026: 3** (drei Live-Läufe, siehe `basiswerte-block0.md` und `umsetzung-protokoll.md` Teil 3). Konfiguriert in `config/newsroom.php`. | 1a.2 |
+| ~~E2~~ | **Empfehlung 01.09.2026: Rohzahlen** — kein Bodensatz, Verteilung symmetrisch, Einordnung gegen den Schnitt wäre wegen der Wachstumskurve falsch (siehe `basiswerte-block0.md`). | 1c.1 |
 | E3 | Anzahl kostenloser Prüfläufe und Preis der weiteren in Credits | 1d.4 |
 | E4 | Trägt die Veröffentlichungsmail den Magic-Link-Hinweis oder den Link auf die Infoseite; ein Element pro Mail | 1b.4, 1d.2 |
 | E5 | Werden die bestehenden Ratgeberseiten konsolidiert oder ergänzt | 2.5 |

dev/2026-09-01/umsetzung-protokoll.md

@@ -547,3 +547,88 @@ stehen in einer eigenen Spalte daneben statt im Nenner.
 Links tragen jetzt zwei Parameter, Blade escapt das trennende `&` korrekt zu
 `&` — der Vergleich läuft nun über `e()`. Verhalten unverändert richtig,
 nur die Erwartung war zu eng.
+
+---
+
+# Teil 3 — Roadmap Block 1a (Newsroom-Konsolidierung)
+
+## 1a.1 — Trockenlauf-Bericht
+
+```
+php artisan companies:merge-report [--threshold=] [--limit=15] [--json]
+```
+
+**Live-Ergebnis vom 11.09.2026, Schwellwert 3, nach der Tippfehler-Korrektur:**
+
+| Klasse | Adressen | Firmen | fällt weg | davon mit PM |
+|---|---|---|---|---|
+| Dublette | 12.812 | 27.832 | **15.020** | 14.633 |
+| Namensvariante | 1.615 | 4.540 | **2.925** | 1.087 |
+| Vorschlag | 3.632 | 9.907 | – | 2.211 |
+| Sammeladresse | 1.085 | 6.706 | – | 1.072 |
+| nie veröffentlicht | 23 | 5.965 | – | 0 |
+
+**17.945 Firmen** würden automatisch zu bestehenden Newsrooms verschmelzen —
+16 % des Bestands von 111.646.
+
+**Drei Befunde aus den Live-Läufen mit Schwellwert 2, 3 und 4:**
+
+1. **Die Klasse „nie veröffentlicht" fehlte im Regelwerk.** 23 Adressen mit
+   5.965 Firmen und null Veröffentlichungen, angeführt von `yahoo@yahoo.com`
+   (4.376 Firmen). Dahinter steht keine Firma und keine Agentur. Hätte 1a.3
+   ohne diesen Trockenlauf gebaut, wären 4.376 Unbeteiligte zu einem Newsroom
+   verschmolzen — der teuerste Fehler dieses Blocks, nicht sauber
+   rückabwickelbar. Die Namensanzahl allein trennt diese Adressen NICHT von
+   großen Agenturen (`pr@deutsche-stadtauskunft.ag`: 133 Namen, 134 Firmen mit
+   Meldungen); trennscharf ist erst die Veröffentlichung.
+2. **Tippfehler galten als verschiedene Firmen.** `info@js-research.de` stand
+   mit 204 Firmen an zweiter Stelle der Agenturliste — eine Firma, siebzehnmal
+   leicht anders geschrieben. Normalisierte Namen werden jetzt zu
+   Ähnlichkeitsclustern zusammengefasst (Levenshtein ≤ 2 bzw. 15 %, oder drei
+   gemeinsame Anfangswörter). Namensvarianten stiegen dadurch von 730 auf 1.615
+   Adressen, Sammeladressen sanken von 1.430 auf 1.085.
+3. **„& Co. KG" passte nie.** Rechtsformen wurden nach dem Entfernen der
+   Satzzeichen abgeglichen — „gmbh & co kg" traf nie auf „gmbh co kg". Jetzt
+   wortweise vom Ende her gestrippt.
+
+**E1 entschieden: Schwellwert 3.** Bei 2 wird jede zweite Schreibweise zur
+„Agentur" (ProCoReX, Welcon — je eine Firma mit Rechtsformwechsel). Bei 4
+wandern 768 echte Mehrkunden-Adressen wie `presse@agentur-zb.de` in die
+Handarbeit. Konfiguriert in `config/newsroom.php`.
+
+**Zu 3.3:** 1.085 Sammeladressen mit 6.706 Firmen, davon 1.072 mit Meldungen —
+namentlich benannte PR-Agenturen. Das Agenturmodell ist kein Zukunftsfeature,
+sondern ein vorhandenes Datenproblem.
+
+## 1a.2 — Persistierte Klassifizierung
+
+```
+php artisan companies:classify-addresses [--threshold=] [--dry-run]
+```
+
+Tabelle `company_email_groups`, eine Zeile je Adresse — die Klassifizierung
+ist eine Eigenschaft der Adresse, nicht der Firma. Bewusst eigene Tabelle statt
+Spalten auf `companies` (FULLTEXT → jedes ADD COLUMN ein Rebuild).
+
+Die Klassifizierungslogik liegt in `CompanyAddressClassifier` und wird von
+Bericht **und** Persistierung benutzt — beide müssen dieselbe Antwort geben,
+sonst zeigt der Bericht etwas anderes, als die Zusammenführung später tut.
+
+**`manual_classification`** übersteuert die berechnete Klasse und überlebt
+jede Neuberechnung. Nötig für Grenzfälle, die nur ein Mensch entscheiden kann:
+`presse@pr4you.de` ist eine echte Agentur, sieht in den Daten aber aus wie eine
+Wegwerfadresse. `CompanyEmailGroup::effectiveClassification()` ist die einzige
+Stelle, die 1a.3/1a.4 fragen dürfen. Wer über eine Adresse entscheidet, liest
+nie die berechnete Spalte direkt.
+
+**Wiederholbar:** Adressen, unter denen nur noch eine Firma steht, fallen beim
+nächsten Lauf heraus — außer sie tragen eine Handentscheidung.
+
+**Laufzeit:** 3,2 s über den ganzen Bestand. Die Ähnlichkeitsprüfung ist
+quadratisch und bei 25 Repräsentanten gedeckelt — ab da steht die Klasse fest,
+und `yahoo@yahoo.com` hätte sonst neun Millionen Levenshtein-Aufrufe gekostet.
+
+**Deploy:** `migrate --force`, `config:cache`, dann einmal
+`companies:classify-addresses`. Der Befehl gehört vorerst nicht in den
+Scheduler — die Klassifizierung soll sich nicht über Nacht ändern, während
+jemand im Admin darüber entscheidet. Nach 1a.4 neu bewerten.