fix: don't apply plugin workflowModules when a workflowBundle is used

[alexrosenfeld10]

What was changed

SimplePlugin.configureWorker and configureReplayWorker no longer inject the plugin's workerInterceptors.workflowModules into worker options when the resolved options contain a workflowBundle. User-provided interceptors.workflowModules are passed through untouched, so the worker's existing warning still fires for explicit user misconfiguration.

Why?

Fixes #2278.

SimplePlugin appended workflowModules unconditionally, so any plugin that ships workflow interceptor modules (e.g. OpenTelemetryPlugin) triggered this on every worker startup when used with a prebuilt bundle:

Ignoring WorkerOptions.interceptors.workflowModules because WorkerOptions.workflowBundle is set.
To use workflow interceptors with a workflowBundle, pass them in the call to bundleWorkflowCode.

This happened even in the documented setup where the plugin was also passed to bundleWorkflowCode (which is what actually includes the interceptors in the bundle, via configureBundler). Module paths cannot be applied to a prebuilt bundle, so injecting them into worker options serves no purpose in that configuration.

Checklist

1. Closes [Bug] OpenTelemetryPlugin + prebuilt workflowBundle always logs "Ignoring WorkerOptions.interceptors.workflowModules" at worker startup #2278

2. How was this tested:

• New test in packages/test/src/test-plugins.ts covering: modules still appended with workflowsPath; not injected when a workflowBundle is passed in options or provided by the plugin itself; user-provided modules passed through; same behavior for configureReplayWorker. Test was written first and observed failing against the previous behavior.
• End-to-end check reproducing the issue scenario: bundleWorkflowCode with OpenTelemetryPlugin (from contrib/interceptors-opentelemetry-v2) followed by Worker.create with the prebuilt bundle and the plugin, capturing runtime logs. Before the fix the warning is logged; after the fix it is not, and the bundle contains the OTel workflow interceptors.
• Full test-plugins.js suite passes locally.

3. Any docs updates needed?

• Updated the workerInterceptors option doc in SimplePluginOptions to describe the behavior.

🤖 Generated with Claude Code

[mjameswh]

1. Let's reverse the gate condition: only include workflowModules interceptors if there's a workflowsPath; that means that a worker with no workflowBundle and no workflowsPath (i.e. non-workflow worker) should not receive any workflowModules.
2. Please follow the same arg structure/order as other resolveXxx methods; the gate condition should be last and should be a boolean (maybe includeWorkflowModules?).
3. I'd argue the extra intermediary resolve function brings no value, yet makes the logic harder to process mentally.

Suggested change

	interceptors: resolveWorkerInterceptorsForOptions(options, workflowBundle, this.options.workerInterceptors),
	interceptors: resolveWorkerInterceptors(options.interceptors, this.options.workerInterceptors, resolvedWorkflowsPath != null),

[alexrosenfeld10]

Reworked in 9c9958d: gate reversed to workflowsPath presence (so non-workflow workers get no workflowModules either), passed as a trailing boolean on resolveWorkerInterceptors, and the intermediary resolve function is removed.

One note on the implementation: since resolveParameterWithResolution returns the parameter directly when existing is undefined (the common case where the user passes no interceptors), the gate strips workflowModules from the object-form parameter up front rather than inside the merge callback. Function-form parameters keep full control of the result, consistent with the other resolvers.