/io latency while 60 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=336ms p50=323ms p99=329ms
/io while 60x /cpu (naive) run concurrently          : total=20 success=20 wall=486ms p50=452ms p99=467ms
/io while 60x /cpu-offloaded run concurrently        : total=20 success=20 wall=398ms p50=377ms p99=387ms

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. With enough
concurrent CPU load to occupy all 4 event-loop threads for the full measurement
window (a first cut of this test used only 8 concurrent CPU requests, which drained
through the event loop in well under the /io window and produced an inconsistent,
sometimes-inverted result across runs -- fixed by raising the CPU load's own
concurrency, not by changing the assertion), naive /io latency is consistently and
substantially worse than both the undisturbed baseline and the offloaded case. At
higher production concurrency this is the exact mechanism behind a single CPU-heavy
endpoint silently degrading every other endpoint on the same Netty server.