fix: preserve tenant context for background alteration jobs

[DenDeline]

Purpose

Preserve the dispatch-time tenant for alteration jobs queued through BackgroundAlterationJobDispatcher, so a plan submitted under a named tenant is executed under that tenant instead of the background worker's ambient tenant.

Scope

• Bug fix (behavior change)

Description

Problem

BackgroundAlterationJobDispatcher captured only the job ID and later created a plain DI scope. DefaultTenantAccessor keeps the current tenant in an AsyncLocal, which does not flow into the mediator's background worker, so the queued job ran under the worker's tenant. With tenant-aware persistence the job lookup returned null, the callback failed, and the job stayed Pending while the plan stayed Running.

Solution

• Capture ITenantAccessor.Tenant synchronously in DispatchAsync and pass it into the queued callback.
• Execute the job inside an ITenantScopeFactory scope created for that tenant (await using), resolving IAlterationJobRunner from the tenant scope. The scope restores the previous tenant on disposal, including when the runner throws. CreateScope(null) keeps the default-tenant path working.
• The dispatcher's constructor now takes IJobQueue, ITenantAccessor, and ITenantScopeFactory in place of IServiceScopeFactory. The service is DI-registered and constructed only through AlterationsFeature; both tenant services are registered by MultitenancyFeature, a declared dependency of WorkflowsFeature.

Tests

BackgroundAlterationJobDispatcherTests (integration) covers: the queued callback runs under the dispatch-time tenant even after the dispatch scope ended and while a different worker tenant is active, and the worker tenant is restored afterward; the same restoration when the runner throws; two jobs for different tenants executing concurrently each observe their own tenant; and dispatch with no tenant pushed executes the runner under the default tenant.

Verification

• dotnet test test/integration/Elsa.Alterations.IntegrationTests/... --filter FullyQualifiedName~BackgroundAlterationJobDispatcherTests -p:CollectCoverage=false: 4 passed.
• dotnet build src/modules/Elsa.Alterations/Elsa.Alterations.csproj: 0 errors, 0 warnings.
• Branch is merged with current main; the pr workflow runs on the merged head.

Greptile's earlier finding about unconditional tenant-service dependencies is answered on the thread: the services are always registered where alterations can run, and a no-op fallback would reintroduce the defect.

Fixes #7961

🤖 Generated with Claude Code

[sfmskywalker]

@greptile

[greptile-apps]

Greptile Summary

This change preserves the tenant present when an alteration job is dispatched and restores that tenant context while the queued job runs. The dispatcher now also unconditionally depends on tenant services, so Alterations registrations that do not enable multitenancy must provide compatible tenant dependencies.

Confidence Score: 4/5

Do not merge without ensuring that Alterations remains usable in installations where multitenancy is not registered.

There is one independent P2, non-security finding. Under the scoring rules, a nonempty finding set containing only P2 findings receives a score of 4.

Files Needing Attention: src/modules/Elsa.Alterations/Services/BackgroundAlterationJobDispatcher.cs

Prompt To Fix All With AI

### Issue 1
src/modules/Elsa.Alterations/Services/BackgroundAlterationJobDispatcher.cs:12-14
**Optional tenant services required**

If a host or direct integration registers Alterations without the optional multitenancy feature, resolving `BackgroundAlterationJobDispatcher` now requires two unavailable tenant services. This prevents the dispatcher from being constructed; gate its registration with multitenancy or support absent/no-op tenant dependencies.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "Fix tenant context propagation for alter..." | Re-trigger Greptile}

[sfmskywalker]

Please review Greptile's comment.

[greptile-apps]

PR author is not in the allowed authors list.

The Greptile finding this review pointed to has been answered and resolved on the thread; current head carries the merged main plus added regression coverage.