Add plugin hooks for activity, Nexus, and worker factory options - #3082

[P1] Version this workflow-visible continuation change

Capturing the registration context changes what an incomplete-promise continuation observes from the completing thread's context to the registering thread's context. That value is workflow-observable, so existing histories can take a different command branch after an SDK upgrade.

I reproduced this on the exact base/head pair: the base ran an async child under context child, registered a continuation under registration, and completed without a timer; replaying that completed history here made the continuation observe registration, emit START_TIMER, and fail with TMPRL1100 because history contained WORKFLOW_EXECUTION_COMPLETED.

Please gate the new semantics behind an SdkFlag so histories without the flag retain the old completion-thread behavior, and add the generated base history as replay coverage. The current new-execution test cannot detect this compatibility break.

[P1] Preserve old behavior for existing factory-only histories

SimplePlugin.addContextPropagators(...) and factory-only plugin installation both existed before this PR, but those propagators previously did not reach workflow child threads. Activating them here silently changes workflow-visible behavior during an SDK upgrade.

I reproduced a second cross-version failure: a base workflow with an existing factory-only plugin created an Async.function child, which saw no parent context and completed without a timer. Replaying that history at this head made the child inherit the context and take a timer branch, again failing with WORKFLOW_EXECUTION_COMPLETED versus START_TIMER.

This path also needs SDK-version gating (or another migration that preserves legacy workflow execution) plus a legacy-history replay test. The merge order and name deduplication themselves look correct.

[P2] Apply the data converter customizer to the activity, Nexus, and schedule clients

configureWorkflowClient applies dataConverterCustomizer, but configureScheduleClient, configureActivityClient, and configureNexusClient do not, although all three option builders expose setDataConverter and the schedule client uses its converter for memos and action payloads. Now that SimplePlugin is an ActivityClientPlugin and a NexusClientPlugin, a codec plugin installed on the service stubs reaches ActivityClient.newInstance(stubs) and NexusClient.newInstance(stubs), but those clients keep GlobalDataConverter while the workers decode with the customized converter, so standalone activity or Nexus inputs are encoded differently from what the worker expects. The schedule half is pre-existing, since that hook used to be a no-op, but has the same shape. Please apply the customizer in all three methods and cover it with tests. This does not block the OpenTelemetry stack, which uses no customizer.

[P2] Correct the continuation threading comment and the compatibility claim

This comment says handlers run in a callback thread created by the runner that inherits its contexts from the workflow header. That is only true for SDK-driven completions such as activities, timers, child workflows, and signals, which arrive through executeInWorkflowThread on a new callback thread. invokeHandlers() below runs the handlers inline on whatever thread calls complete(), so a promise completed by an Async.function child runs the continuation on that child thread with its creation-time context. Before this change a continuation therefore observed the completing thread's context; after it, the registering thread's. That is the workflow-visible difference behind the P1 above, and it also makes the PR description's "Breaking changes? None" inaccurate. Please rewrite the comment to describe the inline invocation and update the description once the SdkFlag gating is in place.