feat(core): DHCP client after Java, measured with Java FILIUS

The client follows Java's DHCPClient instead of Swift: one DISCOVER or
REQUEST per attempt, an answer that does not fit is read and dropped, the
ARP check waits a round trip (an answer for the address ends it at once,
then DECLINE), a timeout repeats the state's message, and the fifth turns
to a link-local address 169.254.1.x/16 (ARP probe, ARP reply to all); no
old address is given back. DHCP round trip times follow the speed as in
Java (50 cables, 2750 ms at 90 %; Swift: fixed 2500 ms).

Not taken from Java: the client gives up after five occupied link-local
addresses (Java searches on without end), and an ARP packet for another
address does not end the check.

dhcpJava.test.ts compares the four DHCP scenarios with DhcpRun's Java
runs; the Swift comparison only checks that they differ.

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

tools/java-oracle/README.md

@@ -172,3 +172,16 @@ 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.
+
+Die RTT ist in Java nicht fest: `Verbindung.holeRTT` = 50 Kabel ×
+Verzögerung je Kabel × RTT-Faktor (Startoption, 1). Beim Anlegen des
+Fensters setzt das Hauptmenü den Regler auf 90 %, also 55 ms je Kabel und
+2750 ms RTT — so laufen die `DhcpRun`-Referenzen; gemessen sind die
+Wartezeiten 2745 bis 2751 ms. Außerdem befördert ein Java-Kabel einen Frame
+nach dem anderen (`SimplexVerbindung` schläft die Verzögerung mit gesperrtem
+Puffer): Sendet eine Karte zwei Frames direkt nacheinander, kommt der zweite
+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).