feat(workflows) Support cross-app workflows

## 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

```typescript
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