Let ContextInternal#isRunningOnContext consider a duplicated context as its original context

[jnbdz]

Motivation

ContextInternal#isRunningOnContext() compares the current context with this by identity. When code runs on a duplicated context — for instance an event-bus consumer handler deployed in a verticle, since messages are delivered on a duplicate of the consumer context — the verticle context reports that it is not running on the context, although the duplicate shares the exact same concurrency model (same event loop / same worker task queue).

Fixes #4576, following the direction discussed there (comparison with the delegate context).

Changes

• isRunningOnContext() now compares the unwrapped contexts: a context, its duplicates and duplicates of duplicates are considered the same context. A null current context is guarded (previously current() == this was simply false). The javadoc states the rule.
• New ContextTest cases:
  • testIsRunningOnContext / testIsRunningOnContextWorker: original ↔ duplicate ↔ duplicate-of-duplicate all report true when running on any of them; a distinct context and its duplicate report false; off-thread reports false.
  • testIsRunningOnContextFromEventBusHandler: the scenario from the issue — a consumer registered in a verticle, message delivered on a duplicate, the verticle context reports true.

Impact

The only internal caller is FutureBase#emitResult. Both of its branches dispatch the listener with the future's own context (beginDispatch/endDispatch), so its observable behaviour is unchanged; when the current thread is on a sibling duplicate it now avoids scheduling an EmitResultTask for what would have been an inline execution anyway.

Verified locally: ContextTest, the future/context/eventbus/deployment suites, Http1xTest, Http2Test and the vertx-core-java21-tests module (virtual threads) all pass.