[BUG] Existing FastEndpoint configuration doesn't work well with Elsa's WorkflowsApiFeature

# Bug Report: Conflict with `AddFastEndpoints` in Elsa's Module Configuration

## Description
Elsa's API feature automatically calls `AddFastEndpoints` within a nested extension method (`AddFastEndpointsFromModule`), causing conflicts for applications that also use FastEndpoints independently. Since FastEndpoints should be registered only once, the current design leads to bad endpoint configuration issues and prevents developers from having full control over their FastEndpoints setup. Furthermore, UseWorkflowsApi calls app.UseFastEndpoints without limiting this configuration to Elsa's own assemblies. This causes endpoints to be mapped multiple times with different configurations.

## Steps to Reproduce

1. Create an application that uses Elsa’s workflow API (`Elsa.Workflows.Api`) and FastEndpoints.
2. Notice that Elsa’s internal call to `AddFastEndpoints` occurs within `ModuleExtensions.AddFastEndpointsFromModule()`.
3. Notice that Elsa’s internal call to `UseFastEndpoints` or within `WebApplicationExtensions.UseWorkflowsApi()` is not limited to elsa's own endpoints, same goes for `MapWorkflowsApi`.
4. Attempt to register additional FastEndpoints in `Program.cs` with a different configuration that conflicts with Elsa (i.e. `c.Endpoints.ShortNames = true;`) using `UseFastEndpoints` or `MapFastEndpoints` after the elsa configuration.
5. Run the application and encounter conflicts due to conflicting endpoint registrations.

**Reproduction Rate**: Always if using mentioned configuration.

## Expected Behavior
1. Leave the configuration of FastEndpoints up to the programmer in the startup.cs
2. Mapping of endpoints is limited to Elsa's own endpoints.

## Actual Behavior
1. Elsa takes over FE configuration itself.
2. Mapping endpoints is not limited to Elsa's own endpoints.

## Troubleshooting Attempts
The following **works** for my use case. *Note:* this is my own specific code, some of this may not be relevant.
1. I have made a copy of the `WorkflowsApiFeature` excluding the call to add FE.
2. I made a static container gathering all the necessary assemblies.
3. I have added those assemblies to the AddFastEndpoint assemblies configuration.
4. Limited the mapping to Elsa('s own name space).
```cs
endpoints.MapFastEndpoints(config =>
{
config.Endpoints.RoutePrefix = "elsa/api";
config.Endpoints.ShortNames = false;
config.Endpoints.Configurator = ep => ep.Tags("elsa");
config.Endpoints.Filter = (ep) => ep.EndpointType.Namespace?.StartsWith("Elsa") == true;
config.Serializer.RequestDeserializer = ElsaSerializers.DeserializeRequestAsync;
config.Serializer.ResponseSerializer = ElsaSerializers.SerializeRequestAsync;
});
```
6. Added Elsa swagger docs by using the tag I added in the snippet above:
```cs
services.SwaggerDocument(o =>
{
// Use elsa tag to filter out endpoints that are not elsa related
o.EndpointFilter = ep => ep.EndpointTags?.Contains("elsa") == true;
// Check if has ElsaEndpoint wrapped class
o.DocumentSettings = s =>
{
s.DocumentName = "elsa";
s.Title = $"ORG (Elsa)";
s.Version = "v1.0";
};
});
```

## Additional Context
I am not sure what the perfect solution would be here.
This convention is used in other places as well (SignalR hub for example).
I get that this is difficult because it's a though line between giving the user too much control and potentially breaking Elsa configuration.

Start by tracing ModuleExtensions.AddFastEndpointsFromModule(), WebApplicationExtensions.UseWorkflowsApi(), and MapWorkflowsApi() to understand where FastEndpoints is registered and mapped. Reproduce the conflict with an external FastEndpoints configuration using the reported ShortNames setting. Done means Elsa leaves application configuration under programmer control and maps only Elsa's endpoints without duplicate registrations.

Written by the indexing model from the issue text.