Assign a distinct event loop to each virtual-thread verticle instance

[Develop-KIM]

Motivation

Deploying a verticle with setInstances(N) and ThreadingModel.VIRTUAL_THREAD pins every instance to the same event loop (vert.x-eventloop-thread-0) instead of distributing them across the event loop group. Raising the instance count therefore stops scaling I/O — the single event loop saturates while the virtual threads starve. This is a regression from Vert.x 4.5.x, where each virtual-thread instance was assigned an event loop via eventLoopGroup.next().

The reporter's k6 load test (setInstances(300), VIRTUAL_THREAD) hit a hard ceiling of ~40k RPS because all 300 instances shared one event loop.

Fixes #5924

Root cause

In DefaultDeployment.deploy(), the VIRTUAL_THREAD branch copied the WORKER pattern: the first instance's event loop was captured in workerLoop and forced on every subsequent instance via .withEventLoop(workerLoop). The EVENT_LOOP branch omits .withEventLoop(...), so ContextBuilderImpl.build() selects the next loop via nettyEventLoopGroup().next() (round-robin).

Change

Build a fresh context for each virtual-thread instance (no shared-loop reuse), so each one round-robins over the event loop group like the event-loop model already does. workerLoop is now used only by the WORKER branch.

Test

DeploymentTest#testDeployInstancesUseDistinctEventLoops deploys 4 VIRTUAL_THREAD instances (8-loop pool) and asserts 4 distinct netty event loops. It fails on the current code (expected:<4> but was:<1>) and passes with the fix; the full DeploymentTest and ContextTest suites remain green.

@vietj — you mentioned possibly making this configurable. This restores the scaling default; happy to layer a toggle on top in a follow-up if you'd prefer.

---

Implemented with AI assistance (Claude); I reviewed, tested and own all changes.