fix(tests): make a stalled integration test fail fast instead of consuming the job

[jbachorik]

Addresses the diagnosability half of #932. Does not claim to fix the flake itself.

Problem

A stalled integration test consumed the entire 30-minute CI budget and reported nothing — no
failing assertion, no stack trace, and seven orphaned JVMs at cleanup. Working out which test had
stalled meant reading the raw job log and comparing timestamps.

Changes

Per-method timeout, five minutes (junit-platform.properties). The whole suite runs in ~12
minutes and the slowest single test is well under the ceiling, so this fires only on a genuine
stall.

SEPARATE_THREAD mode is deliberate rather than incidental: the default interrupts the test
thread, and a thread blocked in socket I/O ignores an interrupt — so a timeout raised that way
would fire and still report nothing, which is the exact failure being fixed.

Bounded target shutdown. TestApp.stop() waited on process.waitFor() with no limit, so a
target that ignores done blocked the test indefinitely. Now 30s, then destroyForcibly(). This
is also the only candidate that accounts for seven orphaned JVMs — one lingering worker thread
does not.

Daemon threads for probe submission. Tests submit to an executor and tear it down with
shutdownNow(), which interrupts; a thread blocked in socket I/O does not answer. A non-daemon
worker in that state keeps the test JVM alive after the class finishes, so the build stalls with
nothing to report. Threads are now named, so a stuck one is identifiable in a dump.

Release the reader before closing the protocol (Client.close()). The command loop blocks in a
read with no timeout — V2 negotiation sets one and restores the previous value, which is unlimited.
Closing the protocol streams first means waiting on that in-flight reader to exit.
sock.shutdownInput() makes the read return, so the closes that follow have nothing to wait on.

Confidence

The first three are correct on their own merits and independent of root cause.

The fourth targets a mechanism inferred from code reading and the CI log shape, not from a
captured dump — 12 local reproduction attempts on macOS all passed, so the stall was never caught
in the act. It is safe regardless (shutdownInput is guarded and inert when no reader is active),
but it should not be considered a confirmed fix for #932 until a stall is caught with a thread
dump. The platform gap is the likely reason local reproduction failed: NioSocketImpl's wake-up of
a blocked reader differs between Linux and macOS, which is precisely the implicated path.

Verification

• Full integration suite: 58 tests pass, no timeout fired, 12m34s on 17.0.19-tem.
• Timeout proven to actually fire: a temporary test sleeping for ten minutes failed at five with
  TimeoutException naming the stalled line. That probe was removed; it is not part of this diff.

The second check matters — "no timeout fired" on its own is equally consistent with a timeout that
is misconfigured and cannot fire.

🤖 Generated with Claude Code

---

This change is 

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.