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>

packages/core/src/runtime/speed.ts

@@ -7,6 +7,8 @@ export const MINIMUM_SPEED_PERCENT = 1;
 export const MAXIMUM_SPEED_PERCENT = 100;
 export const DEFAULT_SPEED_PERCENT = 90;
 export const JAVA_MINIMUM_LINK_DELAY_MILLISECONDS = 5;
+/** Java's Verbindung.MAX_HOPS: the round trip time is this many cables. */
+export const JAVA_MAXIMUM_HOPS = 50;
 
 export class RuntimeSpeed {
   readonly percent: number;
@@ -25,6 +27,14 @@ export class RuntimeSpeed {
     return JAVA_MINIMUM_LINK_DELAY_MILLISECONDS * this.javaDelayFactor;
   }
 
+  /**
+   * Java's Verbindung.holeRTT: how long an answer may take, 50 cables (2750 ms
+   * at the default 90 %). Java's RTT factor (a start option, 1 to 5) is 1.
+   */
+  get roundTripTimeMilliseconds(): number {
+    return JAVA_MAXIMUM_HOPS * this.linkTransmissionDelayMilliseconds;
+  }
+
   /** A base delay scaled like a cable, or undefined past the safe integer range. */
   scaledLinkDelay(baseMilliseconds: number): number | undefined {
     const delay = baseMilliseconds * this.javaDelayFactor;