feat(workflows) Support cross-app workflows

[WhitWaldo]

Summary

Add support for multi-app workflows in the Dapr JS SDK, enabling a workflow orchestrator running in one application to schedule activities that execute in different applications (services).

Background

Currently, workflow activities are registered and executed within the same application that hosts the workflow orchestrator. In a microservices architecture, it's common to want a central orchestrator to coordinate work across multiple services — e.g., an order workflow that calls a payment service, an inventory service, and a shipping service.

Dapr's service invocation and pub/sub building blocks already support cross-app communication. Multi-app workflow support would allow the workflow engine to leverage this, scheduling activities to run on remote applications via Dapr's app-to-app infrastructure.

Proposed API

function* orderWorkflow(ctx: WorkflowContext, input: Order) {
  // Activity runs in the "payment-service" app
  const paymentResult = yield ctx.callActivity(chargePayment, input.payment, {
    appId: "payment-service",
  });

  // Activity runs in the "inventory-service" app
  yield ctx.callActivity(reserveInventory, input.items, {
    appId: "inventory-service",
  });

  // Activity runs locally (no appId specified)
  yield ctx.callActivity(sendConfirmation, { orderId: input.id, paymentResult });

  return { status: "completed" };
}

Design Considerations

• How remote activity invocation maps to Dapr service invocation (gRPC or HTTP)
• Whether the remote app needs to register the activity with its own WorkflowRuntime or if any Dapr-invocable endpoint works
• Error handling and retry semantics for cross-app calls
• How this interacts with Dapr's resiliency policies
• Whether sub-workflows can also target remote apps (ctx.callSubWorkflow(wf, input, { appId: "..." })) (defer to how .NET handles this)

Acceptance Criteria

• callActivity supports an optional appId option to target a remote application
• Remote activities are invoked via Dapr service invocation
• Failures in remote activities are surfaced correctly to the orchestrator
• Integration test with at least two apps demonstrating cross-app activity execution
• Documentation covering multi-app workflow patterns