docs(#151): BW-Datenmodell-Inkompatibilitaet vermerkt

Vertiefte Probe (WP17 Sitzung 50): BW stimmt 'pro Artikel'
('Damit ist Artikel 1 einstimmig zugestimmt'), nicht pro Drucksache.

Das ist andere Datenmodellierung als NRW (Drucksache→Vote) und BUND
(Beschlussempfehlung→Vote). Ein BW-Parser braucht entweder:
- Aggregations-Heuristik: alle Artikel angenommen → DS angenommen
- Schema-Erweiterung um 'artikel'-Spalte fuer per-Artikel-Records

Implementer muss vor Start mit Maintainer abstimmen, welcher Weg
gegangen wird. BW bleibt Stub bis Designwahl getroffen ist.

app/protokoll_parsers/bw.py

@@ -51,6 +51,30 @@ Stichprobe-Analyse von `17_0050.pdf` (618 KB, ~617k Zeichen):
 - Fuer namentliche Abstimmungen (3/Sitzung) ist eigene Logik noetig
   (separate Tabelle im PDF).
 
+## **WICHTIG — Datenmodell-Inkompatibilitaet**
+
+Vertiefte Probe (Sitzung 17_0050):
+- Anchor-Phrase ``Damit ist Artikel 1 einstimmig zugestimmt`` (3x)
+- ``Damit ist Artikel 2 mehrheitlich zugestimmt`` (1x)
+- Aber **keine direkten** ``Damit ist Drucksache X angenommen``-Anchors
+
+**BW stimmt pro Gesetzentwurf-Artikel ab**, nicht pro Drucksache. Das
+ist eine andere Datenmodellierung als NRW (Drucksache → Vote) und
+BUND (Beschlussempfehlung → Vote). Ein BW-Parser muesste:
+
+1. Pro Gesetzentwurf alle Artikel-Anchors sammeln
+2. Aggregat bilden: Gesetzentwurf X = wenn alle Artikel angenommen
+3. Drucksache aus dem zugehoerigen Gesetzentwurf-Header oben rueckwaerts
+   suchen (nicht trivial — der Bezug ist mehrere Seiten zurueck)
+
+Alternative-Modellierung: Schema ``plenum_vote_results`` um optionalen
+``artikel``-Spalten-Pfad erweitern, um pro-Artikel-Records zu speichern.
+
+**Empfehlung fuer Implementer:** vor Parser-Start mit Maintainer
+abstimmen, ob BW-Datenmodell ggf. eigenen Tabellen-Anbau noetig macht
+oder eine BW-spezifische Aggregations-Heuristik (alle Artikel zugestimmt
+→ Gesetzentwurf-DS=angenommen) genuegt.
+
 ## Bezug
 
 - Architektur: ADR 0009 (Plenarprotokoll-Parser-Registry)