fix(workflows): authenticate the BPMN API client

[sfmskywalker]

Closes #1034. Part of elsa-workflows/elsa-core#7909.

Problem

In a live run (Elsa.Server.Web plus Elsa.Studio.Host.Server, signed in as admin), every BPMN call from Studio returned 401, while the other clients on the same session got 200:

System.Net.Http.HttpClient.IWorkflowDefinitionsApi.ClientHandler  Received HTTP response headers - 200
System.Net.Http.HttpClient.IBpmnInterchangeApi.ClientHandler     Received HTTP response headers - 401

AddWorkflowsCore registered the local Refit client as .AddRemoteApi<IBpmnInterchangeApi>() without a BackendApiConfig, so the client never got the host's AuthenticationHandler. Import BPMN, Export BPMN and the Performed-by panel were all unusable against an authenticated server. The bug came in with #1012. The unit tests missed it because they fake IBackendApiClientProvider.

Fix

This follows the AddDashboardModule / AddDashboardModule(BackendApiConfig) pattern:

• A new overload, AddWorkflowsModule(BackendApiConfig backendApiConfig), registers the module and then AddRemoteApi<IBpmnInterchangeApi>(backendApiConfig).
• The config-less registration is removed from AddWorkflowsCore. Microsoft.Extensions.Http registrations for the same client name add up rather than replace each other, so keeping it would have left two competing pipelines.
• Every host now passes the backendApiConfig it already builds: Host.Server, Host.Wasm, Host.CustomElements and samples/BlazorApp1. Host.HostedWasm does not call the module. The snippet in the Dashboard README is updated, since it is the only doc that shows the call.

Compatibility note: a third-party host that keeps calling the parameterless AddWorkflowsModule() still gets an unauthenticated BPMN client. That is the same behaviour as the parameterless AddDashboardModule() today. Such hosts should switch to the config overload, as every host in this repo now does.

Tests

• WorkflowsModuleAuthenticationTests builds the container the way a real host does (AddRemoteBackend plus AddWorkflowsModule(backendApiConfig)) and swaps only the primary HttpMessageHandler. It then calls the real registered client and asserts that the header stamped by the configured authentication handler is present.
• Mutation: reverting to the config-less registration turns it red ("The given header was not found").
• Elsa.Studio.Workflows.Tests: 447/447. The full solution builds on all TFMs.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

No merge-blocking defects were identified; run the focused .NET regression test in an environment with the .NET SDK before merging.

What we checked:

• T-Rex attempted the focused workflows authentication regression test that resolves the BPMN client and invokes its export operation, but the test could not start because the dotnet executable was not found on the system path.

Summary

• The BPMN interchange client registration now uses the backend API configuration-aware workflows module overload, and host composition roots were updated to provide that configuration.

• T-Rex validation blocked The focused BPMN authentication registration test could not run because the .NET SDK is unavailable in this environment (dotnet: command not found).

_{Reviews (1) · Last reviewed commit: "fix(workflows): authenticate the BPMN AP..."}