test(java-oracle): DhcpRun records DHCP as Java FILIUS runs it

Builds a core scenario's network in Java FILIUS, starts it as the action
mode does and writes every frame each card saw (the Lauscher) and the
addresses at the end. References for the four DHCP scenarios: one
DISCOVER/REQUEST per attempt, an ARP check that waits one RTT, DECLINE on a
conflict, link-local 169.254.1.x after the fifth failure.

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

tools/java-oracle/README.md

@@ -139,3 +139,36 @@ mit weniger als fünf Feldern lässt Java die ganze Datei verwerfen
 überspringt Java, statt sie zu zählen; eine Nachricht mit leerem Text geht
 verloren, weil `split` leere Felder am Ende abschneidet. Beim Client gewinnt
 die letzte Zeile, auch eine kaputte, die das Konto leert.
+
+## DHCP zur Laufzeit
+
+`DhcpRun` baut das Netz eines Kern-Szenarios (`packages/core/test/scenarios/*.scenario.json`:
+Knoten, Kabel, Geräte, DHCP-Server und -Clients; die Schritte bleiben
+unbeachtet) in Java-Filius nach und startet es wie der Aktionsmodus
+(`starten()` jeder Systemsoftware). Nach der angegebenen Echtzeit schreibt es
+nach `<name>.java.json`, was jede Netzwerkkarte gesehen hat (Filius' eigener
+Mitschnitt, der `Lauscher`: Zeit, MACs, ARP-Operation und -Adressen,
+IP/UDP-Adressen und -Ports samt DHCP-Text), und die Adressen jedes Rechners
+am Ende. Die MAC eines Ports ist dieselbe wie im Kern (`mac`, sonst
+`stableGeneratedMacAddress`).
+
+* Switches und DHCP-Server starten zuerst: Javas Client wartet auf jeden
+  aktiven Server, findet sie aber über die Knotenliste der Oberfläche, die das
+  Werkzeug nicht hat.
+* `GUIContainer.getGUIContainer()` wird vor dem Start einmal aufgerufen. Im
+  echten Filius steht das Fenster schon; ohne das legen zwei Clients den
+  Singleton gleichzeitig an (nicht synchronisiert), und einer von ihnen
+  sendet nie etwas (gemessen am Szenario `dhcp-lan`).
+* Die Zeiten schwanken von Lauf zu Lauf um einige zehn Millisekunden (echte
+  Threads), die Link-Local-Adresse würfelt Java mit `Math.random`. Die
+  Reihenfolge der Nachrichten eines Clients und ihr Inhalt schwanken nicht.
+
+Gemessen (30.09.2026), was Swift anders macht: Je Versuch sendet Java genau
+ein DISCOVER bzw. REQUEST und wartet dann bis zu einer RTT (2,5 s) auf die
+Antwort; eine unpassende Antwort (etwa das Angebot des zweiten Servers) liest
+es und verwirft sie. Vor dem REQUEST prüft es die angebotene Adresse per ARP
+und wartet dabei eine RTT; antwortet ein anderer Rechner, lehnt es mit
+DHCPDECLINE ab. Javas Server übergeht das DECLINE und hält die Adresse
+weiter als Angebot fest (4 RTT). Nach dem fünften Fehlversuch (Zeitablauf)
+nimmt der Client eine Link-Local-Adresse `169.254.1.x/16`: ARP-Probe, eine
+RTT warten, dann ein ARP-Reply an alle.