Track Cloudflare Workers runtime support blocked by node:vm dependency

Workflow currently depends on Node's node:vm module for workflow execution (runInContext / VM contexts). That blocks Cloudflare Workers runtime implementations: even with nodejs_compat, Wrangler/Workers currently expose node:vm as a non-functional unenv stub, so calling vm.runInContext() fails with:

[unenv] vm.runInContext is not implemented yet!

This means community Cloudflare worlds can provide storage/queue backends, but a workbench deployed directly to Cloudflare Workers cannot run the actual Workflow e2e suite until Workflow has a runtime execution path that does not rely on node:vm.

Relevant community-world PRs:

• https://github.com/vercel/workflow/pull/1477
• https://github.com/vercel/workflow/pull/1964

Likely related work: @TooTallNate's QuickJS snapshot runtime PR, which appears to remove the node:vm dependency as a side effect:

• https://github.com/vercel/workflow/pull/1300

I tested a minimal Wrangler worker locally with compatibility_flags = ["nodejs_compat"] that imports node:vm and calls vm.runInContext("1 + 1", vm.createContext({})); it returns a 500 with the unenv error above.

Once the QuickJS/snapshot runtime or another Worker-compatible execution path lands, we should be able to revisit Cloudflare Workers e2e coverage for these community worlds.

Start by tracing the workflow execution path that uses node:vm and review the related QuickJS snapshot runtime and community-world PRs. Reproduce the failure with the minimal Wrangler worker described in the issue. Done means a Worker-compatible execution path no longer depends on the non-functional node:vm stub and Cloudflare Workers e2e coverage can be revisited.