HTTP SSE read deadline cannot fire while the stream is byte-silent

[senor14]

Found during an adversarial review of 0.6.0 while preparing a downstream conformance test.

HttpMcpTestClient.readSseUntilResponse checks its deadline only after BufferedReader.readLine() returns:

while ((line = reader.readLine()) != null) {
    if (System.nanoTime() > deadline) {
        break;
    }
    ...
}

Two consequences:

1. A byte-silent stream blocks forever. If a server holds the POST SSE stream open and sends no bytes at all (no keep-alives — e.g. a keep-alive interval of 0, or a server that just stalls), readLine() never returns and the deadline is unreachable. The method's own Javadoc claims the deadline means a server that never responds "fails the test with a message instead of hanging the build" — that only holds when the server keeps sending something. The request-level HttpRequest.timeout() doesn't help; it covers response headers only.
2. A response arriving just past the deadline is discarded, not returned. The break happens before the just-read line is parsed, so a response landing at deadline+ε turns into the IllegalStateException instead of a (late) success.

The 0.6.0 fix is still correct for the case it targeted (keep-alive streams, where lines keep arriving and the deadline fires within one keep-alive period) — this is the remaining gap.

Proposed fix for 0.7.0: enforce the deadline independently of line arrival — a watchdog that closes the stream at the deadline so readLine() unblocks with an exception (then translated into the timeout message), or a timed read via the async subscriber API. Regression test: a server mode that goes byte-silent after the handshake.

[senor14]

Two more findings in the same header-only-timeout class, both on the close path (HttpMcpTestClient.close()):

1. The re-interrupt guard is dead code. catch (IOException | InterruptedException ignored) clears the interrupted status when the caught exception is InterruptedException (JDK blocking-method contract), so the if (Thread.currentThread().isInterrupted()) check inside the catch is always false on that path and the interrupt is silently swallowed. Every other interrupt catch in the codebase (post(), McpTestClient, StdioMcpTestClient) re-interrupts unconditionally — close() is the sole deviation. Fix: split the catch, or re-interrupt when ignored instanceof InterruptedException.
2. The session DELETE body is unbounded. It uses BodyHandlers.discarding() with only the request-level timeout (headers only), so a server answering DELETE with a never-ending body blocks close() indefinitely. Fold the body deadline into the fix for the main issue above.

Both for 0.7.0 alongside the byte-silent-stream deadline.