feat(taiga): Status zurückschreiben — zwei Knöpfe, niemand gewinnt von selbst (D91-Nachtrag 8, SPEC §9)

Weicht der Ticket-Status von der Statusbox ab, markiert das Knoten-Fenster
die Abweichung und bietet beide Richtungen ausdrücklich an.

- „nach Taiga schreiben": Spalte des Projekts suchen (Taiga schreibt nach Id,
  die Namen sind je Projekt frei) und mit der zuletzt GELESENEN `version`
  patchen — hat jemand dazwischen geändert, lehnt Taiga ab und der Text steht
  im Fenster, statt dass etwas überschrieben wird.
- „aus Taiga übernehmen": `setStatusBox()` schreibt die Box in die Textzeile,
  undo-fähig wie jede andere Änderung.
- Schreibbar sind nur die fünf abgebildeten Zustände; `[?]`, `[!]`, `[-]` und
  der neutrale Knoten lassen das Ticket unangetastet — mit Begründung im
  Fenster.
- Proxy: zwei Spaltenlisten (`/taiga/{userstory,task}-statuses?slug=`) und
  zwei Schreib-Endpunkte (`PATCH …/{ref}/status?slug=`); die Zielspalte wählt
  der Editor, das Backend parst die Notation nicht (D14).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

backend/CLAUDE.md

@@ -81,3 +81,10 @@ docs/SPEC.md §10 testen — niemals eine zweite, abweichende Grammatik pflegen.
   deshalb den `slug` (aus `&taiga.<slug>`, SPEC §1) und fragen erst
   `/projects/by_slug`, dann `by_ref` — der Slug kommt vom Client und wird
   **kodiert** angehängt, sonst hängte ein `&` darin einen weiteren Filter an.
+- **Schreiben (D91-Nachtrag 8):** `PATCH /taiga/{userstories|tasks}/{ref}/status`
+  nimmt die Status-**Id** (aus `GET /taiga/{userstory|task}-statuses?slug=`)
+  und die zuletzt gelesene `version` — Taigas optimistische Sperre; ein
+  Konflikt wird durchgereicht, nie überschrieben. Die Zielspalte wählt der
+  Editor: Namen sind je Projekt frei, die Abbildung ist Notation (D14). Der
+  Test-Stub muss **chunked** Bodies lesen (der JDK-HttpClient sendet ohne
+  `Content-Length`) — sonst meldet er einen Versionskonflikt, den es nicht gibt.