/io latency while 8 concurrent CPU-bound requests run, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
=======================================================================================================
/io alone (baseline, no concurrent CPU load)        : total=20 success=20 wall=345ms p50=329ms p99=342ms
/io while 8x /cpu (naive) run concurrently          : total=20 success=20 wall=390ms p50=365ms p99=383ms
/io while 8x /cpu-offloaded run concurrently        : total=20 success=20 wall=379ms p50=342ms p99=357ms

This is the real cost of the naive endpoint, and it does not show up by benchmarking
/cpu in isolation: /io shares the same small event-loop pool with /cpu. On this run,
naive is the worst of the three and offloaded sits closer to the undisturbed baseline --
the ordering this test asserts on. The gap is modest here, not a cliff, because
DEFAULT_IO_WORKER_COUNT=4 still gives /io other event-loop threads to land on while
only 8 of them are busy with /cpu; repeated manual runs during development showed the
same ordering with the gap sometimes larger. At higher concurrency, or with a smaller
ratio of event-loop threads to CPU-endpoint traffic, the same mechanism is what turns
into the much larger production outage this pattern is known for -- this box is simply
too small and too lightly loaded, at this concurrency, to force that worse case.