IBKR: Zeitkontext einer Verbindung nachvollziehbar machen

ResolveExecutionTime liefert neben dem UTC-Zeitpunkt jetzt die Herkunft der
verwendeten Zeitzone (gemeldet / angenommen / unbekannt / unlesbar). Bisher war
im Nachhinein nicht unterscheidbar, ob ein Buchungszeitpunkt von TWS stammte
oder eine Annahme war - genau der Fehler, der beim Umzug zwischen EU- und
US-Host lautlos entsteht.

IbkrConnection schreibt beim Verbinden einmalig Betriebszeitzone, Systemzeitzone
und den Versatz zur TWS-Serverzeit ins Log; ab 5 s Abweichung gilt die Uhr des
Hosts als verstellt.

TWS-Setup-Checkliste um den Linux-Abschnitt ergaenzt (Betrieb und Umgebung
unterscheiden sich, das Protokoll nicht).

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

docs/TWS-Setup-Checkliste.md

@@ -68,7 +68,9 @@ der Adapter ab und bleibt inaktiv, statt auf dem falschen Konto zu handeln.
 
 ## 7. Verifikation
 
-- [ ] Port erreichbar? `Test-NetConnection 127.0.0.1 -Port 4002` → `TcpTestSucceeded: True`
+- [ ] Port erreichbar?
+      Windows: `Test-NetConnection 127.0.0.1 -Port 4002` → `TcpTestSucceeded: True`
+      Linux:   `ss -ltn '( sport = :4002 )'` bzw. `nc -zv 127.0.0.1 4002`
 - [ ] API-Verbindung: Verbindungstest ausführen (Konto-ID, NetLiquidation, Positionen müssen
       kommen). Hängt der Handshake > 10 s → Trusted IP fehlt (Punkt 3) oder Popup offen.
 
@@ -108,6 +110,103 @@ bei jeder Kursanfrage der Normalfall, die Kurse kommen danach trotzdem.
 - Einstellungsänderungen im API-Dialog immer mit **Übernehmen/OK** abschließen; solange der
   Dialog offen ist, gelten sie nicht.
 
+## Unterschiede unter Linux
+
+Gilt für TWS bzw. IB Gateway auf einem Linux-Host. **Am Protokoll ändert sich nichts**: dieselbe
+Java-Anwendung, dieselben Ports, derselbe Einstellungsdialog, dieselbe API-Version. Der Adapter
+(`IBKRTrader.Core/Trading/Ibkr/`) braucht keine Anpassung – das TWS-API-Paket referenziert nur
+`mscorlib`, `System` und `System.Core`, keine Windows-Assembly, und der Core baut fehlerfrei für
+`linux-x64` (geprüft 2026-08-04).
+
+Anders sind Betrieb und Umgebung:
+
+| Thema | Windows | Linux |
+|---|---|---|
+| Installationsverzeichnis | `C:\Jts` | `~/Jts` |
+| Einstellungen (inkl. Trusted IPs) | verschleiertes Unterverzeichnis je Login | genauso, unter `~/Jts` |
+| Start | Desktop-Sitzung vorhanden | **X-Server nötig** – headless: `Xvfb` |
+| Auto-Login/Neustart | IBC als geplanter Task | IBC als **systemd**-Unit (der besser unterstützte Weg) |
+| Port prüfen | `Test-NetConnection` | `ss -ltn` / `nc -zv` |
+
+### Worauf konkret zu achten ist
+
+- [x] **Grafische Sitzung.** TWS ist eine GUI-Anwendung und startet ohne Display nicht.
+      **Unser Aufbau:** Ubuntu-Desktop-VM mit gespiegelter Bildschirmfreigabe per RDP – also eine
+      echte, dauerhaft laufende X-Sitzung. Damit entfällt die Xvfb-Frage, und der Einstellungsdialog
+      (Punkt 3) ist jederzeit erreichbar. **Wichtig:** gespiegelte Freigabe, **keine**
+      RDP-Remoteanmeldung – eine eigene Anmeldesitzung startet einen zweiten Desktop, in dem das
+      laufende TWS nicht sichtbar ist und die Sitzung beim Abmelden mitgeht.
+      (Nur für einen echten headless Server wäre `Xvfb` + `x11vnc` nötig.)
+- [ ] **Schriftarten installieren** (`fontconfig` plus z. B. `dejavu`). Fehlen sie, startet die
+      Java-Oberfläche gar nicht oder rendert leer – die häufigste Stolperfalle bei schlanken Images.
+- [ ] **Einstellungen neu setzen, nicht kopieren.** Die API-Einstellungen hängen am Login-Profil
+      unter `~/Jts`. Auf dem neuen Host Punkte 3–5 dieser Checkliste einmal komplett durchgehen.
+- [ ] **Offline-Installer bevorzugen.** Der selbstaktualisierende Installer kann TWS unbemerkt auf
+      eine neue Version heben, die eine andere API-Serverversion spricht.
+- [ ] **Zeitzone je Instanz setzen.** `Trading.ApplicationTimeZoneId` steuert die Betriebszeitzone
+      und ist **unabhängig** von der des Hosts. EU-Instanzen `Europe/Berlin`, US-Instanzen
+      `America/New_York`. TWS meldet Ausführungszeiten teils mit, teils ohne Zonenangabe – ohne
+      Angabe greift dieser Wert als Rückfall. Wie sich das im Betrieb beobachten lässt, steht
+      unten unter „Zeitverhalten beobachten".
+- [ ] **ICU im Image sicherstellen** (`libicu` / `icu-data-full`). Die Zonenauflösung nutzt
+      IANA-IDs (`US/Eastern`); ohne ICU wirft `FindSystemTimeZoneById`. Die Projekte setzen
+      deshalb bewusst `InvariantGlobalization=false` – siehe `IBKRTrader.Daemon.csproj`.
+- [ ] **Schreibrechte des Dienstbenutzers** auf `~/Jts` prüfen. Bei systemd mit eigenem `User=`
+      braucht dieser ein echtes Home-Verzeichnis. Für die App selbst regelt `AppPaths` die
+      Ablage bereits FHS-konform.
+- [ ] **Java-Heap** in `tws.vmoptions` (im Installationsverzeichnis) prüfen, wenn viele
+      Instrumente abonniert werden – gleiche Datei wie unter Windows, anderer Pfad.
+- [ ] **Wenn TWS und App auf verschiedenen Rechnern laufen:** „Nur Verbindungen vom lokalen Host“
+      aus, IP der App-Maschine als Trusted IP eintragen – und weil der API-Socket **unverschlüsselt**
+      ist, nur über VPN oder SSH-Tunnel, nie offen übers Netz.
+
+> Diese Liste beruht auf Erfahrungswerten zum TWS-Betrieb, **nicht** auf einer Messung auf einem
+> Linux-Host – anders als der Rest dieser Checkliste. Beim ersten Aufsetzen entsprechend prüfen
+> und die Punkte hier korrigieren.
+
+## Zeitverhalten beobachten (Paper-Phase)
+
+Zwischen einer EU- und einer US-Instanz ist die Zeitzone die gefährlichste Stelle: Ein falscher
+Wert wirft keinen Fehler, er verschiebt nur Buchungszeiten. Damit das während der Paper-Phase
+auffällt statt später im Echtbetrieb, schreibt der Adapter drei Dinge mit (Modul `IBKR`).
+
+**1. Zeitkontext bei jedem Verbindungsaufbau** – eine Info-Zeile, die den gesamten Rahmen festhält:
+
+```
+Zeitkontext: Betriebszeitzone Europe/Berlin, Systemzeitzone Europe/Berlin,
+TWS-Serverzeit 2026-08-04 15:39:18Z, Uhrenversatz +0.2 s.
+```
+
+Damit lässt sich jeder spätere Zeitfehler an einer Zeile aufklären, statt im Nachhinein zu raten,
+wie die Instanz konfiguriert war.
+
+**2. Uhrenversatz gegen den TWS-Server.** Mehr als 5 s Abweichung ergeben eine **Warnung**. In
+virtuellen Maschinen ist eine driftende Uhr ein häufiger Fehler – besonders nach Snapshots oder
+Pausieren der VM.
+
+**3. Herkunft jedes Ausführungs-Zeitstempels.** Nach jedem Abruf steht im Log, wie viele Zeitpunkte
+TWS **mit** Zonenangabe gemeldet hat und wie viele über die Betriebszeitzone **angenommen** wurden:
+
+```
+Zeitstempel von 2 Ausführung(en): 0 mit gemeldeter Zone, 2 über die Betriebszeitzone Europe/Berlin.
+```
+
+Beobachtungsstand 2026-08-04: `execDetails` lieferte die Zeit **ohne** Zonenangabe
+(`"20260804  17:39:18"`), `reqCompletedOrders` dagegen **mit** (`"... Europe/Berlin"`). Der
+Normalfall beim Ausführungsabruf ist also die Annahme – genau deshalb wird sie gezählt.
+
+### Worauf zu achten ist
+
+| Logmeldung | Bedeutung | Reaktion |
+|---|---|---|
+| `Uhrenversatz` über 5 s | Host-Uhr läuft auseinander | Zeitsynchronisation der VM prüfen |
+| `... wurden gegen die Betriebszeitzone X gerechnet, das System läuft aber auf Y` | Betriebs- und Systemzeitzone gehen auseinander | Prüfen, gegen welche Uhr TWS meldet; einmal mit dem TWS-Fenster gegenlesen |
+| `Ausführung(en) mit unlesbarem Zeitstempel` | TWS-Format hat sich geändert | Defekt – `IbkrMapping.ResolveExecutionTime` anpassen |
+
+**Gegenprobe beim Aufsetzen einer Instanz:** Eine Ausführung im TWS-Fenster ansehen und die dort
+angezeigte Uhrzeit mit der gebuchten vergleichen. Stimmen beide, ist die Zeitzone richtig gesetzt.
+Das kostet zwei Minuten und ist die einzige verlässliche Probe – alles andere ist Papier.
+
 ## Unterschiede Live-Betrieb (später)
 
 | Punkt        | Paper                  | Live                                    |