Instanzmanager Stufe 4: eine Adresse, ein Zugang, alle Instanzen (#528, E-M5)

Der Managerprozess. ClawdDotNet.Instanzmanager ist eine Konsolenanwendung:
Lizenz pruefen, uebernehmen was laeuft, Weboberflaeche aufhaengen, warten.
Beim Herunterfahren beendet er keine Instanz.

Zwei neue Projekte. ClawdDotNet.Manager.Web traegt die Weboberflaeche -
ohne jeden Verweis auf ClawdDotNet.Web, denn dort haengt App und daran
sechzehn Werkzeugprojekte. ClawdDotNet.ManagerApp ist der Einstiegspunkt.
wwwroot ist aus der Instanz in den Manager gezogen.

DER SCHNITT DER HTTP-FLAECHE: Unter /api/verwaltung steht, was den Manager
angeht - auflisten, anlegen, starten, anhalten. Alles andere unter /api
geht unveraendert an eine Instanz. Er leitet weiter, er implementiert
nicht. Welche Instanz gemeint ist, sagt die Kopfzeile X-Instanz; laeuft
genau eine, ist sie gemeint, und laufen mehrere, wird nachgefragt statt
geraten - eine Anfrage an die falsche Instanz ist schlimmer als eine
abgelehnte.

Der zusammengefuehrte Ereignisstrom haelt je laufender Instanz eine
Zuleitung und schreibt an jedes Ereignis, von wem es kommt. Ergaenzt statt
verpackt: Ein Umschlag waere einfacher gewesen, haette aber jede Ansicht
der Weboberflaeche zum Umschreiben gezwungen.

ABNAHME gegen laufende Prozesse: 401 ohne Token, Oberflaeche ohne Token
200, Instanz ueber den Manager gestartet und angehalten, /api/info und
/api/status unverfaelscht durchgereicht, /events/logs mit
"instanz":"Instance-Test" an jeder Zeile. Manager abgeschossen: Instanz
laeuft weiter. Manager neu gestartet: "1 Instanzen bekannt, 1 laufen
bereits" - uebernommen. E-M6 damit in beide Richtungen belegt.

DREI DEFEKTE, die erst der Lauf gezeigt hat:

1. Der Manager hing an einer Konsolenabfrage nach dem Lizenzschluessel. Ein
   Test auf Console.IsInputRedirected reicht dafuer NICHT: Er beantwortet
   "ist die Eingabe umgeleitet", nicht "kann jemand antworten" - ein
   Prozess ganz ohne Konsole, der gefaehrlichste Fall, ist nicht
   umgeleitet. Der Manager fragt jetzt gar nicht.
2. Eine unlesbare manager.json wurde stillschweigend durch Vorgaben
   ersetzt: falsches Instanzverzeichnis, anderer Port, Lizenzfrage - und
   nichts sagte, woran es lag. LoadProblem meldet den Grund jetzt.
3. Der Instanzprozess erbte CLAWD_CONFIG_DIR vom Manager und legte sich in
   dessen Konfigurationsverzeichnis eine eigene Settings.json an. Eine
   Umgebungsvariable vererbt sich, ein Argument nicht - der Manager nimmt
   sein Verzeichnis jetzt ueber --config.

SharedLoggerProvider ist nach Core gezogen: Es gibt jetzt zwei Webhosts,
die dasselbe brauchen, und sie duerfen einander nicht kennen.

NOCH OFFEN in dieser Stufe: Die Weboberflaeche kennt noch keine Instanzen -
Instanzauswahl, X-Instanz und die Verwaltungsansicht sind Arbeit an
wwwroot. Und webServerPort steht noch in der Instanz.

Build ohne Warnungen, 775 Tests gruen, 8 uebersprungen.

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

docs/Instanzmanager-Konzept.md

@@ -322,7 +322,7 @@ Verbindung und führt sie zusammen, mit der Instanzkennung an jedem Ereignis.
 | 1 ✔ | Einstellungen und Protokolle je Instanz trennen (Abschnitt 6) | Zwei Instanzen gleichzeitig, keine schreibt der anderen ins Protokoll |
 | 2 ✔ | Instanzprozess kopflos lauffähig, Kestrel auf dem Socket | Eine Instanz läuft ohne Fenster, der Socket antwortet |
 | 3 ◑ | Manager: anlegen, starten, anhalten, Prozessaufsicht, Lizenz, Sub-Token | Eine Instanz abschießen — der Manager merkt es und meldet es |
-| 4 | Weboberfläche zieht um, Weiterleitung, ein Ereignisstrom | Eine Adresse, ein Zugang, Wechsel ohne Neustart |
+| 4 ◑ | Weboberfläche zieht um, Weiterleitung, ein Ereignisstrom | Eine Adresse, ein Zugang, Wechsel ohne Neustart |
 | 5 | Instanzfenster als eigener Prozess, Wechsel holt das Fenster nach vorn | Kein Neustart mehr beim Wechseln |
 | 6 | Sicherungen im Manager (falls Abschnitt 7 dafür entscheidet) | Zurückspielen hält die Instanz an und startet sie wieder |
 
@@ -549,3 +549,65 @@ Sockets hinterlegt, *bevor* der Manager hochfuhr — damit sagt man „diese Ins
 bereits", der Manager übernimmt sie (E-M6), der Starter wird nie angefasst, und der Test
 prüft etwas anderes, als er behauptet. Es gibt jetzt eine Hilfsmethode, die genau das
 ausschließt.
+
+### 9.5 Was Stufe 4 gebracht hat
+
+**Den Managerprozess.** `ClawdDotNet.Instanzmanager` ist eine Konsolenanwendung: Sie prüft
+die Lizenz, übernimmt, was läuft, hängt die Weboberfläche auf und wartet. Sie beendet beim
+Herunterfahren keine Instanz.
+
+**Zwei neue Projekte.** `ClawdDotNet.Manager.Web` trägt die Weboberfläche — ohne jeden
+Verweis auf `ClawdDotNet.Web`, denn dort hängt `App` und daran sechzehn Werkzeugprojekte.
+`ClawdDotNet.ManagerApp` ist der Einstiegspunkt. `wwwroot` ist aus der Instanz in den
+Manager gezogen (Abschnitt 8).
+
+**Der Schnitt der HTTP-Fläche.** Unter `/api/verwaltung` steht, was den Manager angeht:
+Instanzen auflisten, anlegen, starten, anhalten. **Alles andere unter `/api` geht
+unverändert an eine Instanz** — er leitet weiter, er implementiert nicht. Welche Instanz
+gemeint ist, sagt die Kopfzeile `X-Instanz`; läuft genau eine, ist sie gemeint, und laufen
+mehrere, wird nachgefragt statt geraten. Eine Anfrage an die falsche Instanz ist schlimmer
+als eine abgelehnte.
+
+**Der zusammengeführte Ereignisstrom.** Der Manager hält je laufender Instanz eine
+Zuleitung und schreibt an jedes Ereignis, von wem es kommt (`instanz`, `instanzName`).
+Ergänzt statt verpackt: Ein Umschlag wäre einfacher gewesen, hätte aber jede Ansicht der
+Weboberfläche zum Umschreiben gezwungen.
+
+**Abnahme, gegen laufende Prozesse gemessen:**
+
+| Geprüft | Ergebnis |
+|---|---|
+| `/api/verwaltung/instanzen` ohne Token | 401 |
+| Oberfläche ohne Token | 200 — die leere Hülle, wie vorgesehen |
+| Instanz über den Manager starten | `Running`, PID 18104 |
+| `/api/info` durchgereicht | Antwort **der Instanz** (`instanceId d68af6fd`) |
+| `/api/status` durchgereicht | 503 der Instanz, unverfälscht |
+| `/events/logs` | Zeilen der Instanz, mit `"instanz":"Instance-Test"` daran |
+| Anhalten über den Manager | `Stopped` |
+| **Manager abgeschossen** | Instanz läuft weiter (E-M6) |
+| **Manager neu gestartet** | „1 Instanzen bekannt, 1 laufen bereits" — übernommen |
+
+**Drei Defekte, die erst der Lauf gezeigt hat:**
+
+1. **Der Manager hing an einer Konsolenabfrage.** `ConsoleLicensePrompt` wartete auf eine
+   Eingabe, die niemand geben konnte; die Weboberfläche kam nie hoch, und im Protokoll
+   stand nichts davon, weil die Frage auf der Standardausgabe steht. Ein Test auf
+   `Console.IsInputRedirected` reicht dafür **nicht**: Er beantwortet „ist die Eingabe
+   umgeleitet", nicht „kann jemand antworten" — ein Prozess ganz ohne Konsole, der
+   gefährlichste Fall, ist nicht umgeleitet. Der Manager fragt jetzt gar nicht; ein
+   Schlüssel gehört in `manager.json`.
+2. **Eine unlesbare `manager.json` wurde stillschweigend durch Vorgaben ersetzt.** Der
+   Manager suchte dann im falschen Verzeichnis, hörte auf einem anderen Port und fragte
+   nach einer Lizenz, die woanders stand — und nichts sagte, woran es lag. Es kostete eine
+   halbe Stunde und einen fehlenden Backslash. `LoadProblem` meldet den Grund jetzt.
+3. **Der Instanzprozess erbte `CLAWD_CONFIG_DIR` vom Manager** und legte sich im
+   Konfigurationsverzeichnis des Managers eine eigene `Settings.json` an. Eine
+   Umgebungsvariable vererbt sich, ein Argument nicht — deshalb nimmt der Manager sein
+   Konfigurationsverzeichnis jetzt über `--config`. Für eine systemd-Unit ist das ohnehin
+   der geradere Weg.
+
+**Was in Stufe 4 noch fehlt:** Die Weboberfläche selbst kennt noch keine Instanzen — sie
+spricht `/api/…` an und bekommt die eine laufende. Instanzauswahl, `X-Instanz` und die
+Verwaltungsansicht sind Arbeit an `wwwroot` und gehören damit in Geminis Spur. Und
+`webServerPort` steht noch in der Instanz: Ihr TCP-Zugang ist erst überflüssig, wenn die
+Oberfläche im Manager vollständig ist.