Autostart durch Manager, mit Sicherungsautomat (#528)

Entschieden vom Benutzer am 2026-09-08. Der Schalter heisst
autostartByManager und steht in InstanceSettings.json - bei der Instanz,
nicht beim Manager.

ZWEI DINGE IN EINEM SCHALTER, weil es dieselbe Zusage ist: Der Manager
startet diese Instanz, wenn er selbst hochkommt, und er startet sie wieder,
wenn sie abstuerzt. Ohne den Schalter ruehrt er nichts an - ein Manager,
der nach einem Neustart der Maschine alles hochfaehrt, was er findet,
startet auch das, was jemand mit Absicht angehalten hat. Ausgeschaltet
vorbelegt.

DER SICHERUNGSAUTOMAT ist der eigentliche Inhalt. Wieder hochzufahren ist
die einfache Haelfte; die schwierige ist zu erkennen, wann man es lassen
muss. Nach drei Neustarts in zehn Minuten (maxRestartsInWindow,
restartWindowMinutes) setzt der Manager aus und meldet es. Die Instanz
bleibt dann aus, bis jemand sie von Hand startet - und dieser Start raeumt
den Zaehler ab, denn wer von Hand startet, hat entweder etwas geaendert
oder weiss, was er tut. Das Zeitfenster wandert: Eine Instanz, die einmal
im Monat abstuerzt und wieder hochkommt, laeuft nie in die Grenze.

Nur bei einem Absturz, nicht wenn eine Instanz verstummt. Eine stumme
Instanz lebt noch; sie neu zu starten hiesse, sie erst abzuschiessen, und
ob der Manager das von sich aus darf, ist nicht entschieden. Als offene
Frage aufgeschrieben - genau dieser Zustand war der Anlass des Vorhabens.

Der Schalter steht bei der Instanz, weil er eine Eigenschaft dieser Instanz
ist und weil die Instanzdatei dem Instanzprozess gehoert: Sie vom Manager
schreiben zu lassen, waehrend die Instanz laeuft, waeren zwei Schreiber auf
einer Datei. Der Manager liest ihn nur; geaendert wird er auf der
Einstellungsseite der Instanz.

EIN DEFEKT, den erst diese Tests gezeigt haben: StartAsync gab "laeuft
schon" zurueck, wenn die Aufsicht die Instanz fuer laufend hielt - ohne
nachzusehen. Zwischen zwei Aufsichtsdurchgaengen liegen aber Sekunden, und
in denen kann sie wegbrechen. Wer in dieser Luecke "starten" verlangte,
bekam einen Erfolg, hinter dem nichts stand, und der naechste Durchgang
meldete einen Absturz, den niemand mehr erwartete. Jetzt wird gefragt,
bevor zugestimmt wird.

UND EIN TESTDOUBLE, das die Wirklichkeit nicht abbildete: Der falsche
Socket antwortete unabhaengig davon, ob ein Prozess lief. Damit war jeder
Testaufbau, der die Antwort vor dem Hochfahren hinterlegte, stillschweigend
ein anderer Test als beabsichtigt - eine Antwort sagt dem Manager "laeuft
bereits", er uebernimmt, und der Starter wird nie angefasst. Dreimal
passiert. Der falsche Socket haengt jetzt am falschen Starter.

Sicherungen im Manager sind als #530 zurueckgestellt, mit Ausloeser.
Vorab entschieden ist dort nur eines: Zurueckspielen ausschliesslich bei
inaktiver Instanz.

19 neue Tests. Build ohne Warnungen, 793 Tests gruen, 8 uebersprungen.

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

tests/ClawdDotNet.Manager.Tests/Doubles.cs

@@ -47,6 +47,15 @@ internal sealed class FakeLauncher : IInstanceLauncher
 
     public int Starts { get; private set; }
 
+    /// <summary>Welcher Prozess zu welchem Instanzverzeichnis gehört.</summary>
+    public Dictionary<string, FakeProcess> ByDirectory { get; } =
+        new(StringComparer.OrdinalIgnoreCase);
+
+    /// <summary>Ob für dieses Verzeichnis gerade ein Prozess lebt.</summary>
+    public bool IsRunning(string instanceDirectory)
+        => ByDirectory.TryGetValue(Path.GetFullPath(instanceDirectory), out var p)
+           && !p.HasExited;
+
     /// <summary>Wenn gesetzt, scheitert der Start damit.</summary>
     public Exception? FailStartWith { get; set; }
 
@@ -63,6 +72,7 @@ internal sealed class FakeLauncher : IInstanceLauncher
 
         Last = new FakeProcess(_nextId++, Now);
         Running[Last.Id] = Last;
+        ByDirectory[Path.GetFullPath(instanceDirectory)] = Last;
         return Last;
     }
 
@@ -95,6 +105,21 @@ internal sealed class FakeChannel : IInstanceChannel
     public Dictionary<string, InstanceIdentity?> AnswerFor { get; } =
         new(StringComparer.OrdinalIgnoreCase);
 
+    /// <summary>
+    /// Wenn gesetzt, antwortet der Socket nur für Instanzen, die dieser Starter
+    /// tatsächlich gestartet hat — so wie im Betrieb.
+    ///
+    /// <para><b>Ohne das ist ein Testaufbau leicht falsch:</b> Wer die Antwort hinterlegt,
+    /// bevor der Manager hochfährt, sagt damit „diese Instanz läuft bereits". Der Manager
+    /// übernimmt sie dann (E-M6), der Starter wird nie angefasst — und der Test prüft etwas
+    /// anderes, als er behauptet. Das ist mir dreimal passiert; mit dieser Kopplung kann es
+    /// nicht mehr passieren.</para>
+    ///
+    /// <para>Nicht gesetzt heißt: Die hinterlegte Antwort gilt immer. Das braucht, wer eine
+    /// Instanz beschreiben will, die läuft, ohne dass dieser Manager sie gestartet hat.</para>
+    /// </summary>
+    public FakeLauncher? Launcher { get; set; }
+
     public int Calls { get; private set; }
 
     /// <summary>Wie oft die Instanz gebeten wurde, sich zu beenden.</summary>
@@ -107,6 +132,9 @@ internal sealed class FakeChannel : IInstanceChannel
     {
         Calls++;
 
+        if (Launcher is not null && !Launcher.IsRunning(instanceDirectory))
+            return Task.FromResult<InstanceIdentity?>(null);
+
         return Task.FromResult(
             AnswerFor.TryGetValue(Path.GetFullPath(instanceDirectory), out var eigene)
                 ? eigene