fix(worker): fix Bandel ticket sync and reactivate the integration

The status PATCH needs statusName alongside statusId or the API 400s,
so every write-back had been silently failing. The board's flat
assigneeName is null on every live ticket; the real assignee list is
ticketAssignees[]. Import now also picks up In Bearbeitung tickets,
not just Offen ones.

Both issues are live-verified against the real API, so the feature
flag flips back on.

docs/open.md

@@ -46,33 +46,35 @@ verifiziert und deshalb hier entfernt. Es bleiben die Entscheidungen, die daran
 
 ## Offene Verifikation (2026-08-27, Ticketsystem-Anbindung)
 
-> **PAUSIERT.** `TicketSettingsTabViewModel.FeatureEnabled = false` versteckt Settings-Tab,
-> Projekt-Dropdown und Kontextmenü-Eintrag; zum Reaktivieren die Konstante umlegen. Grund: die
-> API ist unter `http://bandelapis.fb-tuning.local` nicht erreichbar (*connection actively
-> refused* — nichts lauscht dort). Kein ClaudeDo-Bug und kein CORS; wahrscheinlich fehlt eine
-> IIS-Hostname-Bindung oder der Port stimmt nicht (`deploy/deploy-iis-winrm.ps1` der API notiert,
-> dass srv-04b diese Sites *by IP:port rather than by hostname* erreicht). Wird mit dem
-> API-Kollegen geklärt. Die Punkte unten bleiben stehen, bis die Erreichbarkeit steht.
+> **Reaktiviert am 2026-09-01.** `FeatureEnabled = true`. Die API läuft unter
+> `http://192.168.45.161` — der Hostname `bandelapis.fb-tuning.local` lehnt die Verbindung
+> weiterhin ab, die Base-URL muss also die **IP** sein.
 
-Tasks 1–9 sind implementiert und gemergt (Build + Tests grün, `_broadcaster.TaskUpdated` genau
-einmal in `TaskStateService.cs`), aber **kein Smoke-Test gegen die echte Bandel-API ist
-gelaufen**. Die fünf Punkte aus der „Manuellen Verifikation" des Specs
-(`docs/superpowers/specs/2026-08-27-ticketsystem-integration-design.md`):
+Alle vier Routen sind jetzt live gegen die echte API geprüft. Die aus dem `Bandel.APIs`-Quellcode
+abgeleiteten Shapes stimmten bis auf zwei Punkte, beide gefixt und mit Tests belegt:
 
-- [ ] PAT in den Settings hinterlegen, „Verbindung testen" → korrekter Benutzername + Scopes.
-- [ ] Liste mit Projekt `393 Bandel.LagerApp` verknüpfen, „Update from Ticketsystem" → nur
-      eigene, offene Tickets erscheinen als Tasks.
-- [ ] Einen Task laufen lassen → Ticket steht im Ticketsystem auf `InBearbeitung`.
+- `PATCH /api/Ticket/{id}/status` braucht **`statusId` UND `statusName`** — ohne den Namen 400
+  („The StatusName field is required."), also hätte *jede* Write-Back fehlgeschlagen. Der Name
+  wird nicht gegen die Id validiert, muss aber nicht-leer sein (`TicketStatusMap.NameOf`).
+- Das flache `assigneeName` im Board-Item ist auf **jedem** Ticket null (alle 63 in Abteilung
+  Entwicklung geprüft). Der Assignee-Filter des Imports hätte damit immer 0 Tasks erzeugt. Echte
+  Quelle: `ticketAssignees[].assigneeName`, das exakt das Format von `/pat/me`s `userName` hat.
+  `personInChargeName` ist die falsche Quelle (mal Login, mal Anzeigename).
+
+Import zieht jetzt `Offen` **und** `InBearbeitung`, weiterhin nur eigene Tickets.
+
+Bleibt manuell zu prüfen (UI-Pfad, nie sichtbar gelaufen):
+
+- [ ] PAT in Settings → Ticketsystem hinterlegen (Base-URL `http://192.168.45.161`),
+      „Verbindung testen" → `mika.kuns` + 9 Scopes.
+- [ ] Liste mit einem Projekt verknüpfen (Rechtsklick → Listeneinstellungen → Ticket-Projekt),
+      „Update from Ticketsystem" → nur eigene offene/laufende Tickets erscheinen als Tasks.
+      Achtung: aktuell ist **kein** offenes Ticket in Entwicklung dir zugewiesen — zum Testen
+      erst im Ticketsystem zuweisen, sonst ist 0 importiert das korrekte Ergebnis.
+- [ ] Einen Task laufen lassen → Ticket steht auf `InBearbeitung`.
 - [ ] Approve/Merge → Ticket steht auf `Fertig`.
 - [ ] Base-URL leeren → Menüeintrag verschwindet, keine Netzwerkaufrufe mehr.
-
-**Wichtig:** die Response-Shapes der Bandel-API (`BandelEnvelope<T>`, `TicketIdentity`,
-`TicketBoardItem`, `SidebarDepartment`/`SidebarProject`, `TicketDtos.cs`) wurden aus dem
-**Quellcode** von `Bandel.APIs` abgeleitet, **nie live gegen die echte API verifiziert** — es gab
-keinen einzigen echten Netzwerkaufruf während der Implementierung. Die Punkte 1–4 oben sind
-zugleich der erste Test dieser Annahme: schlägt einer davon mit einem Deserialisierungs- oder
-404/Formatfehler fehl, ist das erwartbar und kein Regressions-Bug — dann müssen die DTOs in
-`src/ClaudeDo.Worker/Tickets/TicketDtos.cs` an die tatsächliche Antwort angepasst werden.
+- [ ] Sichtprüfung des Settings-Tabs + des Ticket-Projekt-Dropdowns (nie gerendert gesehen).
 
 ## Offene Verifikation (2026-07-27)