fix(efcore): run domain-event scrapers on managed multi-tenancy commit path

[outofrange-consulting]

Problem

Under managed multi-tenancy (AddDbContextWithWolverineManagedMultiTenancy<T>), domain events registered via PublishDomainEventsFromEntityFrameworkCore<T>(x => x.Events) are silently never published. A handler can mutate/persist an entity that raises a domain event, the transaction commits, but the event never reaches the outbox.

Root cause

The EF Core transactional middleware has two codegen paths:

• The single-DbContext path commits through EfCoreEnvelopeTransaction.CommitAsync() (Internals/EfCoreEnvelopeTransaction.cs), which runs the registered IDomainEventScrapers — emitted by CommitEfCoreEnvelopeTransaction (Codegen/EnrollDbContextInTransaction.cs).
• The managed-multitenancy path commits the raw EF transaction directly in CommitTenantedDbContextTransaction.GenerateCode (Codegen/StartDatabaseTransactionForDbContext.cs) and never invokes CommitAsync(). The enlisted EfCoreEnvelopeTransaction is built (Internals/TenantedDbContextBuilderByConnectionString.cs BuildAndEnrollAsync), but at runtime inside the DbContext builder — so it is never surfaced as a codegen variable and its scraper loop is unreachable from the generated chain.

Fix

Inline the scrape loop into CommitTenantedDbContextTransaction, resolving IEnumerable<IDomainEventScraper> exactly as EnrollDbContextInTransaction.FindVariables does and running it before the commit + flush — mirroring EfCoreEnvelopeTransaction.CommitAsync(). The GH-2917 ordering (commit + flush in the postprocessor before the HTTP response writer) and the IFlushesMessages contract are preserved, so no duplicate flush is introduced.

Surfacing the enlisted EfCoreEnvelopeTransaction as a codegen variable (the cleaner alternative) is not feasible on this path: the DbContext and its transaction are constructed at runtime inside BuildAndEnrollAsync, never returned as a codegen variable, so FindVariable(typeof(EfCoreEnvelopeTransaction)) would throw at generation time.

Test

Adds domain_events_scraping_with_managed_multi_tenancy under EfCoreTests.MultiTenancy, the managed-multitenancy counterpart of the single-DbContext scraper tests in EfCoreTests/DomainEvents/configuration_of_domain_events_scrapers.cs. It approves an entity under a tenant and asserts the scraped domain event is published via a tracked session. The test fails on main and passes with this change. Existing PostgreSQL multitenancy suites (cascading messages, HTTP posts, sagas, outbox) still pass; the empty-scraper case resolves to an empty enumerable, identical to the single-DbContext path.

Affected versions

V6.0.0 – V6.5.1 and main. The omission predates and is independent of #2920 / GH-2917, which only concern commit/flush ordering relative to the HTTP response writer.

[jeremydmiller]

@outofrange-consulting Why are you even using the domain event scraping? Was that legacy code you retrofitted to Wolverine?