fix(quic-interop): wake the driver in prepareRequest (serial path)

The longrtt testcase (1 file, serial path) was failing because
client.get(authority, path) → prepareRequest() opens a stream and
queues the GET, but never calls driver.wakeup(). The data sits in
the queue until the PTO timer fires (~1 s later) — a fatal delay
on a 1.5 s RTT link with an 8 s docker-compose timeout.

The parallel path explicitly wakes after prepareRequests returns,
but the serial path was missing the equivalent nudge.

Smoking gun from the inspect-testcase output:
  - 1 KB file, handshake at t=4502, response packets at t=4684/4685
  - NO outgoing packet between t=4499 (ack) and t=4687 (ack) that
    contained the GET request — it never went out via prepareRequest

Fix: prepareRequest in both Http3GetClient and HqInteropGetClient
now calls driver.wakeup() after enqueuing the request. The
@Suppress("UNUSED_PARAMETER") on HqInteropGetClient.driver was
also stale — it's used now.

quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/HqInteropGetClient.kt

@@ -39,7 +39,7 @@ import kotlinx.coroutines.flow.toList
  */
 class HqInteropGetClient(
     private val conn: QuicConnection,
-    @Suppress("UNUSED_PARAMETER") private val driver: QuicConnectionDriver,
+    private val driver: QuicConnectionDriver,
 ) : GetClient {
     override suspend fun prepareRequest(
         @Suppress("UNUSED_PARAMETER") authority: String,
@@ -49,6 +49,8 @@ class HqInteropGetClient(
         val request = "GET $path\r\n".encodeToByteArray()
         stream.send.enqueue(request)
         stream.send.finish()
+        // Wake the send loop — same reasoning as Http3GetClient.
+        driver.wakeup()
         return HqRequestHandle(stream)
     }
 

quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/Http3GetClient.kt

@@ -151,6 +151,13 @@ class Http3GetClient(
         val stream = conn.openBidiStream()
         stream.send.enqueue(encodeRequest(authority, path))
         stream.send.finish()
+        // Without this, the data sits in the queue until the PTO
+        // timer fires (~1 s later). On the longrtt scenario (750 ms
+        // one-way, 1.5 s RTT) that's a fatal delay — the runner's
+        // 8 s timeout doesn't leave room for the PTO + RTT + RTT
+        // dance. The parallel path wakes after the chunk; the
+        // serial path was missing the same nudge.
+        driver.wakeup()
         return Http3RequestHandle(stream)
     }