Fix flaky ConductorTest latch timeouts caused by ChaosTest starving the common ForkJoinPool

[maxdml]

Problem

CI intermittently fails a random ConductorTest with message latch timed out (e.g. canGetWorkflowEventsThrows()[3] in run 79520581511, failing all 3 retries).

Root cause: ChaosTest.toxiProxyTest launched dbLossBetweenSteps via a bare CompletableFuture.supplyAsync(...), which runs on the JVM-shared common ForkJoinPool. While the test's toxiproxy partition is active (~3s), that worker sits blocked inside SystemDatabase.dbRetry backoff loops. On CI runners the common pool has only ~3 workers, and the run's logs show the pool fully stalled for 3.2s — with zero common-pool activity — exactly spanning all three retries of the failing test.

The Conductor's WebSocket callbacks (onOpen/onText) and message handlers also dispatch on the common pool, so during the stall the conductor client never completed its handshake: the test server saw onOpen and sent the request, but the client-side connect future was still pending when Conductor.stop cancelled it at teardown. Suite-wide, the test server saw 113 handshakes while the client completed only 106.

The flake only reproduces when a ConductorTest happens to overlap one of ChaosTest's induced partitions, which is why it comes and goes.

Fix

Run the deliberately-blocked startWorkflow on a dedicated thread instead of the common pool. A platform thread is used (not virtual) because the module targets --release 17.

Testing

• :transact:compileTestJava passes
• CI=true ./gradlew :transact:test --tests dev.dbos.transact.database.ChaosTest.toxiProxyTest: all 5 repetitions pass (test is ci-only-tagged)

Note

This removes the known trigger, but the Conductor still depends on the common pool for its WebSocket callbacks and handlers (Conductor.java:795+). Anything that saturates the common pool for >1s could reproduce the symptom, including in production. Giving the Conductor an explicit executor is a possible follow-up.

[devhawk]

Should we run this test @isolated and/or @execution(ExecutionMode.SAME_THREAD)?

[maxdml]

Same thread would have supplyAsync run on the same coomon pool and isolated slows down test without really solving the problem