test(java-oracle): TcpRun records TCP as Java FILIUS runs it

Three stories of socket calls on tcp-lan's network (exchange, closedPort,
lostData): every frame with TCP flags and numbers, when each call started,
returned or failed, and each socket's states. Network building and the
packet log move from DhcpRun to ScenarioNetwork.

Measured: 3 RTT per attempt (8250 ms at 90 %), an orderly close after a
failed send, TIME_WAIT of 3 RTT, the passive side closing by itself on FIN,
one SYN only (Java's retry loop ends after the first timeout).

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

tools/java-oracle/README.md

@@ -185,3 +185,40 @@ eine Kabellänge später.
 Filius' Mitschnitt selbst ist dabei nicht ganz zuverlässig: Starten zwei
 Clients zugleich, fehlt auf der Karte des zweiten dessen eigenes DISCOVER
 (vier von vier Läufen von `dhcp-lan`; der Server empfängt es).
+
+## TCP zur Laufzeit
+
+`TcpRun` spielt auf dem Netz von `tcp-lan` (Server 192.168.0.10, Clients .20
+und .30) einen festen Ablauf von Socket-Aufrufen ab, wie Filius' Anwendungen
+sie machen, den Server in einem eigenen Thread. Es schreibt nach
+`tcp-java-<ablauf>.java.json` die Frames jeder Karte (mit TCP-Flags,
+Sequenz- und Bestätigungsnummer), wann jeder Aufruf begann, zurückkam oder
+scheiterte, und jeden Zustand jedes Sockets (alle 2 ms abgefragt). Netzbau
+und Mitschnitt teilen `DhcpRun` und `TcpRun` in `ScenarioNetwork`.
+
+* `exchange`: Verbindung zu Port 80, `GET /`, Antwort 3000 × `x` (drei
+  Segmente), der Client schließt, der Server eine Sekunde nach
+  `CLOSE_WAIT`.
+* `closedPort`: Verbindung zu Port 81, auf dem niemand lauscht.
+* `lostData`: verbunden, dann gehen alle Frames verloren
+  (`Verbindung.setDrop`, wie der Paketverlust des Kerns), während der Client
+  sendet; der Verlust endet, wenn `senden` scheitert.
+
+Gemessen (30.09.2026, 90 %, RTT 2750 ms), was Swift anders macht:
+
+* Jeder Versuch wartet 3 RTT (8250 ms): Daten gehen dreimal hinaus (1720,
+  9970, 18220 ms), `senden` scheitert 8250 ms nach dem dritten.
+* Scheitert `senden`, schließt Java ordentlich: FIN, ACK, FIN, ACK. Swift
+  setzt den Socket ohne FIN auf CLOSED.
+* `TIME_WAIT` dauert 3 RTT (8250 ms; oder bis zum nächsten Segment), nicht
+  eine RTT.
+* Die Gegenseite schließt von selbst: Kommt ein FIN, geht Javas
+  Socket-Thread aus `listen` in `close` und sendet sein FIN sofort
+  (`LAST_ACK` rund 60 ms nach dem FIN), nicht erst, wenn die Anwendung
+  `schliessen` aufruft.
+* Der Client sendet nur **ein** SYN: Nach dem ersten Zeitablauf setzt
+  `connectClientMode` `closeSocket`, und die Schleife über drei Versuche
+  endet (`verbinden` scheitert nach 3 RTT). Der Server-Socket wiederholt sein
+  SYN+ACK nie.
+* Startnummern aus einem Zähler über alle TCP-Sockets (1000000, 2000000, …),
+  wie im Kern; der freie Port ist zufällig.