Instanzmanager: Register, Einstellungen und stellvertretende Meldung (#528)

Der zweite Teil von Stufe 3. Die Aufsicht ueber eine einzelne Instanz stand
schon; jetzt gibt es die Klammer darum und den Weg nach draussen.

InstanceRegistry haelt je Instanz eine Aufsicht. Zwei Zusagen, beide aus
E-M6: Beim Start wird UEBERNOMMEN, nicht gestartet - ein Manager, der beim
Hochkommen alles hochfaehrt, was er findet, startet nach einem Neustart der
Maschine auch das, was jemand mit Absicht angehalten hat. Und beim Beenden
wird nichts beendet: Wer den Manager schliesst, will den Manager
schliessen. Einzige Ausnahme ist StopAllAsync fuer einen Grund, der alle
betrifft - und der heisst Lizenzwiderruf.

SupervisionReporter macht aus einem Befund eine Bugtracker-Meldung,
stellvertretend: mit Prozesskennung, Abschiedscode und dem Ausschnitt aus
dem Instanzprotokoll, der noch auf der Platte liegt. Der Idempotenzschluessel
ist stabil je Instanz und Art - stuerzt dieselbe Instanz wiederholt ab,
zaehlt der Server hoch, statt den Bugtracker mit Zwillingen zu fuellen.

Ein leerer Protokollauszug ist dabei die aussagekraeftigste Zeile der
Meldung und wird ausdruecklich als solche geschrieben. Genau das war der
Zustand am 2026-09-08: Der Prozess wurde erschlagen, bevor sein
Schreibpuffer geleert war, und hinterliess nichts.

manager.json traegt die Felder aus Abschnitt 6 des Konzepts und sonst
nichts. Lizenzschluessel, Master-Token und Web-Token liegen darin
verschluesselt und zur Laufzeit im Klartext - dieselbe Bauart wie die
Anwendungseinstellungen, mit Absicht. Unsinnige Aufsichtswerte werden
eingefangen, weil die Datei von Hand bearbeitbar ist.

InstanceLayout ist nach Core gezogen (ResolveLogDirectory,
ResolveBackupDirectory). Der Manager braucht das Protokollverzeichnis einer
Instanz fuer den Auszug in der Meldung und darf ClawdDotNet.App nicht
kennen; dieselbe Rechnung an zwei Stellen zu fuehren waere die schlechtere
Antwort. AppHost leitet nur noch weiter.

EIN DEFEKT, den erst die eigenen Tests gezeigt haben: Eine angehaltene
Instanz erschien im Register als "Instance-Alpha" statt "Alpha". Die
Aufsicht kennt den Namen erst, wenn die Instanz einmal geantwortet hat, und
eine angehaltene tut das nie - waehrend genau diese Ansicht der Manager
anzeigt. Das Register fuehrt den Namen jetzt aus InstanceSettings.json mit.

Und ein Testdouble, das zu viel behauptet hat: Der falsche Socket
antwortete fuer jedes Verzeichnis dieselbe Instanz. Das laesst Tests gruen
werden, die im Betrieb zwei Instanzen verwechseln wuerden; er antwortet
jetzt je Verzeichnis.

29 neue Tests. Build ohne Warnungen, 766 Tests gruen, 8 uebersprungen.

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

docs/Instanzmanager-Konzept.md

@@ -456,6 +456,36 @@ und meldet es", und zum Neustarten trifft dieses Papier keine Entscheidung. Eine
 in einer Schleife wieder hochzufahren, die jedes Mal abstürzt, wäre die falsche Vorgabe
 für etwas, das niemand entschieden hat. **Das ist eine offene Frage** — siehe Abschnitt 7.
 
+**Das Register und die stellvertretende Meldung.** `InstanceRegistry` hält je Instanz eine
+Aufsicht und hat zwei Zusagen, die beide aus E-M6 folgen: Beim Start wird *übernommen*,
+nicht gestartet — ein Manager, der beim Hochkommen alles hochfährt, was er findet, startet
+nach einem Neustart der Maschine auch das, was jemand mit Absicht angehalten hat. Und beim
+Beenden wird nichts beendet: Wer den Manager schließt, will den Manager schließen. Die
+einzige Ausnahme ist `StopAllAsync` — für einen Grund, der alle betrifft, und der heißt
+Lizenzwiderruf.
+
+`SupervisionReporter` macht aus einem Befund eine Meldung im Bugtracker, **stellvertretend**:
+mit Prozesskennung, Abschiedscode und dem Ausschnitt aus dem Protokoll der Instanz, der
+noch auf der Platte liegt. Der Idempotenzschlüssel ist stabil je Instanz und Art — stürzt
+dieselbe Instanz wiederholt ab, zählt der Server hoch, statt den Bugtracker mit Zwillingen
+zu füllen; wiederholte Abstürze sind ein Befund und nicht ein Dutzend gleicher.
+
+**Ein leerer Protokollauszug ist die aussagekräftigste Zeile der Meldung.** Genau das war
+der Zustand aus 1.1: Der Prozess wurde erschlagen, bevor sein Schreibpuffer geleert war,
+und hinterließ nichts. Die Meldung sagt das ausdrücklich, statt eine leere Stelle zu
+lassen.
+
+**`manager.json`** trägt die acht Felder aus Abschnitt 6 und sonst nichts. Lizenzschlüssel,
+Master-Token und Web-Token liegen darin verschlüsselt und zur Laufzeit im Klartext — wie
+in den Anwendungseinstellungen, mit Absicht dieselbe Bauart. Unsinnige Aufsichtswerte
+(Abfragetakt 0, Alarm nach null Fehlversuchen) werden eingefangen: Die Datei lässt sich von
+Hand bearbeiten.
+
+**Ein Defekt, den erst die Tests gezeigt haben.** Eine angehaltene Instanz erschien als
+`Instance-Alpha` statt `Alpha` — die Aufsicht kennt den Namen erst, wenn die Instanz einmal
+geantwortet hat, und eine angehaltene tut das nie. Genau diese Ansicht zeigt der Manager
+aber an. Das Register führt den Namen jetzt aus `InstanceSettings.json` mit.
+
 **Abnahme, mit echten Prozessen gemessen.** Der Manager hat die Instanz `Test` in 0,7 s
 gestartet und über die Named Pipe identifiziert, die Zustandsdatei geschrieben
 (`pid=54476`, `id=d68af6fd`), dann wurde der Prozess von außen abgeschossen. Der nächste