Add scoped operator controls and durable worker release queue

docs/web-console.md

@@ -70,8 +70,8 @@ Die Oberfläche bietet ein einfaches Formular für neue wowdiag-/wowsrc-Aufträg
 für abgeschlossene ZIP-Akten mit Testerfeedback. Es verwendet dieselbe Multipart-
 API und denselben Idempotenzmechanismus wie externe Programme. Bei unveränderten
 Eingaben verwendet eine Wiederholung denselben Schlüssel. Anhänge und Fallakten
-werden nicht clientseitig bearbeitet. Administrative Worker-Eingriffe bleiben ein
-weiterer Ausbauschritt.
+werden nicht clientseitig bearbeitet. Betreiberaktionen stehen separat berechtigten
+Clients zur Verfügung.
 
 ## Fallakte und Ergebnisse
 
@@ -88,8 +88,43 @@ Die Revisionsauswahl liest akzeptierte Artefakte aus der Checkpointhistorie der
 aktuellen vollständigen Akte. Ergebnisse neuerer Revisionen erscheinen nicht in
 älteren Ansichten. Über die Übergabe-API erfasste Patch-Rückmeldungen werden bis
 zur gewählten Revision dargestellt. Bei gesperrten Fällen erscheinen Sperrgrund
-und passende Betreiberhinweise; die Ansicht setzt keine Budgets zurück und hebt
-keine Sperren auf.
+und passende Betreiberhinweise. Für berechtigte Betreiber kann eine zulässige
+Fortsetzung angefordert werden; Budgets werden dabei nicht zurückgesetzt.
+
+## Betriebssteuerung
+
+Clients erhalten standardmäßig keine Betreiberrechte. Ein eigener Client mit
+eigenem Token und `operator = true` in der API-Konfiguration erhält Aktionen für
+seine freigegebenen Projekte (Beispiel in `config/api.example.toml`). API nach einer
+Rechteänderung neu starten. Der Gemini-Schlüssel ist dafür nicht geeignet.
+
+- **Neue Fälle pausieren / wieder zulassen:** gilt je Projekt und bleibt nach
+  Neustart erhalten. HTTP-Aufträge werden weiterhin dauerhaft angenommen. Der
+  Worker lässt sie im Eingang bzw. wartet bei noch nicht begonnenen Fällen.
+  Begonnene Analysen laufen weiter. Eine Pause unterbricht keinen Modellaufruf.
+- **Fortsetzung nach Fehlerbehebung anfordern:** in der aktuellen Falldetailansicht
+  bei passenden Schedulerfehlern bzw. `RESEARCH_UNAVAILABLE`. Die API bestätigt
+  nur `QUEUED`, nicht bereits eine Freigabe. Der lebende Worker prüft den Auftrag
+  zwischen Dispatches erneut; ein gestoppter Worker bearbeitet ihn nach Neustart.
+- Veraltete Paketgeneration, geänderte Konfigurationsbindung, noch nicht fällige
+  Research-Sperre und unzulässige fachliche Sperren werden abgewiesen. Keine
+  Zurücksetzung von Hypothesenbudgets, Versuchszählern oder LLM-Operationen.
+- Das Aktionsprotokoll dokumentiert Clientkennung, UTC-Zeit, Projekt, Aktion und
+  Ergebnis. Fortsetzungen haben getrennte Eingangs- und Ausführungseinträge mit
+  derselben Auftragskennung. Die Ansicht zeigt die letzten 100 berechtigten
+  Einträge; das vollständige Protokoll bleibt unter `runtime/worker/control/`.
+  Es enthält keine Tokens oder Konfigurationsinhalte. Erfolgreiche lokale
+  CLI-Freigaben erscheinen als `local-cli`.
+- Workerdetails zeigen Erreichbarkeit, letzten Zustand, Aktivität und Fehlercode.
+  Ein alter Snapshot gilt nicht als lebender Worker. Globale Workerdetails sind
+  nur Betreibern mit Zugriff auf alle konfigurierten Projekte zugänglich.
+
+`GET /v1/operations` liefert Rechte, projektbezogenen Pausenzustand und für Betreiber
+Protokoll/Workerzustand. `POST /v1/operations` benötigt Betreiberrechte und JSON:
+`{"action":"pause","project_id":"viano-core"}` bzw. `resume`, oder
+`{"action":"retry","key":"<Schlüssel aus der Übersicht>","package_generation":42}`.
+Bei gleichzeitigem Zugriff kann `API_CONTROL_BUSY` auftreten; nach Aktualisierung
+erneut versuchen. Der Worker muss nach diesem Softwareupdate neu gestartet werden.
 
 `GET /v1/cases/{key}?revision=N` liefert diese projektgebundene Ansicht.
 `GET /v1/cases/{key}/package` lädt die vollständige aktuelle Akte einschließlich