Evaluate the EF Core persistence provider before Marten regardless of registration order

[jeremydmiller]

Closes #3359. Follow-up to #3353/#3357.

In a mixed Marten + EF Core application, which persistence provider owned an entity for storage actions, [Entity] loading, and saga persistence silently depended on the order the two integrations were registered in Program.cs. Writing the registration-order permutation tests surfaced two root causes, not one:

1. Ordering: MartenPersistenceFrameProvider.CanPersist claims every type (Marten genuinely can persist any document) and TryFindPersistenceFrameProvider takes candidates.First() — so whichever integration registered last sat at index 0 via InsertFirstPersistenceStrategy and claimed everything, including EF-mapped entities.
2. Registration swallow: AddDbContextWithWolverineIntegration registered its Wolverine extension with TryAddSingleton<IWolverineExtension, …>, which gates on the service type alone. If any other integration (e.g. Marten's IntegrateWithWolverine()) had already registered an IWolverineExtension, the EF Core codegen integration — persistence provider, batching policy, query-spec policy — was never registered at all. This went unnoticed because UseEntityFrameworkCoreTransactions() applies the same extension eagerly via options.Include<>(); only apps relying on AddDbContextWithWolverineIntegration alone were bitten.

Changes

• New IPersistenceFrameProvider.IsCatchAll default-interface member (default false). The catch-all document stores override it to true: Marten, Polecat, RavenDb, CosmosDb, and the in-memory provider. EF Core stays selective — it only claims types actually mapped in a registered DbContext model.
• New GenerationRulesExtensions.OrderedPersistenceProviders(): selective providers first, catch-alls last, registration order preserved within each group (stable sort). Consumed by TryFindPersistenceFrameProvider, GetPersistenceProviders, SagaPersistenceChainPolicy, and the service-capabilities saga tagger (which documents that it mirrors the codegen precedence). AutoApplyTransactions is untouched — it already only applies when exactly one provider matches.
• AddDbContextWithWolverineIntegration now uses TryAddEnumerable(ServiceDescriptor.Singleton<IWolverineExtension, EntityFrameworkCoreBackedPersistence>()), which dedupes on the (service, implementation) pair — idempotent across repeated calls without being swallowed by other integrations' extensions.
• Docs: new "Combining EF Core with Marten" section in the EF Core integration guide stating the deterministic rule.

With EF Core first, EF-mapped entities deterministically resolve to their DbContext and every other document still falls through to Marten — nothing only Marten can persist is taken away from it.

Tests

• PersistenceTests.persistence_provider_precedence_permutations: Marten-then-EFCore and EFCore-then-Marten hosts, each asserting an Item mapped in SampleDbContext resolves to EFCorePersistenceFrameProvider and an unmapped document resolves to MartenPersistenceFrameProvider. Red-first verified: with the production changes stashed, both permutations fail (one via ordering, one via the swallowed registration).
• CoreTests.Persistence.persistence_provider_precedence: 5 unit tests for the ordering primitive with fake selective/catch-all providers, including stable-order-within-group.

Verification

• CoreTests full: 1905 passed / 0 failed
• EfCoreTests full: 186/187 (lone failure is the documented Bug_1846 load-flake; passes isolated)
• PersistenceTests full: 68/69 (lone failure using_dynamic_multi_tenancy is a pre-existing full-suite flake — it also fails on unfixed baseline binaries and passes in isolation)
• Full wolverine.slnx Release build: 0 warnings / 0 errors
• Rebased on main including Enlist Lightweight-mode HTTP storage-action chains in the EF Core outbox (GH-3353) #3357; permutation + unit tests re-verified green post-rebase

🤖 Generated with Claude Code