Add virtual-threads-benchmark-webflux: the WebFlux leg of the three-way benchmark

Re-uses the platform/virtual-thread transcripts already committed in
virtual-threads-benchmark rather than re-measuring them, and adds a WebFlux
module measured the same way (client-side java.net.http.HttpClient load
generator against a real Netty server). Covers I/O-bound throughput, a
naive-vs-offloaded CPU-bound comparison that turned up a real, counter-
intuitive fact about this sandbox's default thread-pool sizes
(LoopResources.DEFAULT_IO_WORKER_COUNT=4 vs Schedulers.parallel()'s
availableProcessors()=2), and an event-loop-starvation scenario showing
what the naive endpoint actually costs unrelated /io traffic on the same
server. Companion code for the ankurm.com post "Virtual Threads vs WebFlux
vs Platform Threads: Benchmarks and a Decision Framework." Also fixes the
root README's module table, which was missing the virtual-threads-benchmark
row from an earlier commit.

virtual-threads-benchmark-webflux/docs/output/01-io-bound-webflux.txt

@@ -0,0 +1,8 @@
+I/O-bound endpoint (/io, Mono.delay(300ms)), concurrency=600, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
+==============================================================================================================
+webflux (netty) : total=600 success=600 wall=897ms p50=596ms p99=780ms
+
+Mono.delay() never parks a thread -- the event loop schedules a timer callback and
+goes back to the selector loop immediately. Wall time for 600 concurrent requests
+stays close to a single 300ms round, same shape as virtual threads' /io result in
+../virtual-threads-benchmark/docs/output/01-io-bound-benchmark.txt.

virtual-threads-benchmark-webflux/docs/output/02-cpu-bound-webflux.txt

@@ -0,0 +1,17 @@
+CPU-bound endpoint (/cpu vs /cpu-offloaded, 20,000x SHA-256), concurrency=60, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
+==============================================================================================================================
+LoopResources.DEFAULT_IO_WORKER_COUNT (Netty event-loop threads) = 4
+Runtime.availableProcessors() (Schedulers.parallel() thread count) = 2
+
+webflux naive (Mono.fromCallable, no subscribeOn)      : total=60 success=60 wall=358ms p50=209ms p99=330ms
+webflux offloaded (subscribeOn(Schedulers.parallel())) : total=60 success=60 wall=324ms p50=171ms p99=283ms
+
+Counter-intuitive result, and worth stating honestly rather than forcing the expected
+story: on THIS box, the two wall times are close, because Reactor Netty's default event-
+loop pool (DEFAULT_IO_WORKER_COUNT = max(availableProcessors(), 4) = 4 here) is actually
+LARGER than Schedulers.parallel()'s pool (sized to availableProcessors() = 2). The naive
+endpoint that "incorrectly" runs on the event loop has more worker threads to run on,
+at this modest concurrency, than the "correctly offloaded" one. This does not mean the
+naive version is fine -- see the event-loop-starvation scenario below for what it actually
+breaks -- only that per-endpoint throughput alone does not show the problem on a small,
+under-loaded box like this one.

virtual-threads-benchmark-webflux/docs/output/03-event-loop-starvation.txt

@@ -0,0 +1,16 @@
+/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.