Instanzmanager Stufe 5: Wechseln heisst nach vorn holen (#528, E-M2)

Vorher hiess "Instanz wechseln": Der laufende Prozess faehrt sich herunter
und startet sich mit einer anderen Instanz neu. Wer wechselte, beendete
zwangslaeufig die Instanz, aus der heraus er es tat - und genau dabei hat
sich die Anwendung am 2026-09-08 aufgehaengt (#529). Jetzt laufen alle, und
es kommt eine nach vorn.

Neu: POST /api/instanz/fenster, wieder ausschliesslich ueber den Socket.
Die Instanz holt ihr Fenster SELBST nach vorn; der Manager kennt kein
Fenstersystem und soll keines kennen. Kopflos laeuft die Bitte ins Leere,
und das ist die richtige Antwort. Das letzte Wort hat der Fenstermanager -
Windows laesst einen Hintergrundprozess den Vordergrund nicht einfach an
sich reissen; der kurze Ausflug ueber Topmost half im Versuch, unter Linux
entscheidet der Fenstermanager. Mehr als bitten kann eine Anwendung nicht.

ShutdownSignal ist zu InstanceControl geworden: beenden und Fenster sind
zwei Bitten desselben Absenders ueber denselben Weg. Beenden gilt einmal,
das Fenster beliebig oft - jeder Wechsel auf diese Instanz ist einer.

--managed schaltet den Wechsel im Instanzfenster ab. Der Manager gibt es
jedem Instanzprozess mit; das Fenster graut seinen Instanz-Schalter aus und
erklaert auf Nachfrage, wo gewechselt wird. Zwei Schloesser an derselben
Tuer: Der Knopf ist aus, und der Weg dahinter prueft es noch einmal - denn
hinter ihm wartet ein Selbst-Neustart.

instanceWindows in manager.json, vorbelegt auf true: Jede Instanz behaelt
ihr Fenster. Auf einer Maschine ohne Bildschirmsitzung gehoert false hin.

ABNAHME an echten Fenstern: Instanz ueber den Manager gestartet, PID 18128,
Fenstertitel "ClawdDotNet", Befehlszeile mit --managed. Fenster von aussen
minimiert (IsIconic True), dann POST /instanzen/Instance-Test/fenster:
IsIconic False, im Vordergrund - und PID unveraendert 18128. Nichts neu
gestartet. Das ist die Abnahmebedingung dieser Stufe.

Build ohne Warnungen, 780 Tests gruen, 8 uebersprungen.

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

docs/Instanzmanager-Konzept.md

@@ -323,7 +323,7 @@ Verbindung und führt sie zusammen, mit der Instanzkennung an jedem Ereignis.
 | 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 |
-| 5 | Instanzfenster als eigener Prozess, Wechsel holt das Fenster nach vorn | Kein Neustart mehr beim Wechseln |
+| 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 |
 
 **Stufe 1 ist die, die man überspringen möchte und nicht überspringen darf.**
@@ -611,3 +611,40 @@ spricht `/api/…` an und bekommt die eine laufende. Instanzauswahl, `X-Instanz`
 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.
+
+### 9.6 Was Stufe 5 gebracht hat
+
+**Der Wechsel ist kein Neustart mehr.** Vorher hieß „Instanz wechseln": Der laufende
+Prozess fährt sich herunter und startet sich mit einer anderen Instanz neu — wer
+wechselte, beendete zwangsläufig die Instanz, aus der heraus er es tat, und genau dabei
+hat sich die Anwendung am 2026-09-08 aufgehängt. Jetzt laufen alle, und es kommt eine nach
+vorn.
+
+**Die Instanz holt ihr Fenster selbst.** Neu ist `POST /api/instanz/fenster`, wieder
+ausschließlich über den Socket. Der Manager kennt kein Fenstersystem und soll keines
+kennen; er bittet, und wer ein Fenster hat, holt es nach vorn. Kopflos läuft die Bitte ins
+Leere, und das ist die richtige Antwort. **Das letzte Wort hat der Fenstermanager** —
+Windows lässt einen Hintergrundprozess den Vordergrund nicht einfach an sich reißen; der
+kurze Ausflug über `Topmost` half im Versuch, unter Linux entscheidet der Fenstermanager.
+Mehr als bitten kann eine Anwendung nicht.
+
+**`--managed` schaltet den Wechsel im Instanzfenster ab.** Der Manager gibt es jedem
+Instanzprozess mit; das Fenster gräut seinen Instanz-Schalter aus und erklärt auf Nachfrage,
+wo gewechselt wird. Zwei Schlösser an derselben Tür: Der Knopf ist aus, und der Weg
+dahinter prüft es noch einmal — hinter ihm wartet ein Selbst-Neustart.
+
+**`instanceWindows` in `manager.json`**, vorbelegt auf `true`: Jede Instanz behält ihr
+Fenster (E-M2). Auf einer Maschine ohne Bildschirmsitzung gehört `false` hin.
+
+**Abnahme, an echten Fenstern gemessen:**
+
+| Geprüft | Ergebnis |
+|---|---|
+| Instanz über den Manager gestartet | PID 18128, Fenstertitel „ClawdDotNet" |
+| Befehlszeile | `--managed --instance …` |
+| Fenster von außen minimiert | `IsIconic = True` |
+| `POST /instanzen/Instance-Test/fenster` | „Fenster von 'Test' nach vorn geholt" |
+| Danach | `IsIconic = False`, **im Vordergrund** |
+| Prozess danach | **PID 18128, unverändert** — nichts neu gestartet |
+
+Die letzte Zeile ist die Abnahmebedingung: kein Neustart mehr beim Wechseln.