Fix [Entity]/storage-action regression for non-EFCore-persisted sagas (#3342)

[jeremydmiller]

Closes #3342.

Symptom (regression 6.4.3 → 6.5.0+)

A saga whose handler returns an EF Core storage action (Insert<T>/Update<T>/…) of a
non-saga entity, then cascades a message whose handler loads that same entity via
[Entity], broke at 6.5.0. The [Entity] load came back null:

• a [Entity(Required = false)] handler threw a NullReferenceException on it, and
• a Required [Entity] handler was silently skipped (so the cascade downstream never ran).

The reporter's OnException(...).Discard() masked the NRE, making it look like "the handler just
didn't execute."

Root cause

#3040 (GH-3039) made EFCorePersistenceFrameProvider's entity overload of
ApplyTransactionSupport a no-op for all saga chains:

if (chain is SagaChain) return;

The intent: defer to the no-entity overload that SagaChain.DetermineFrames calls after every
IHandlerPolicy, so a policy-set transaction mode is honored. But DetermineFrames calls the
persistence provider that owns the saga's own state. When the saga is persisted by a different
store (here the SqlServer message store) and only its storage action uses EF Core, EF Core's
no-entity overload is never called — so the blanket early-return dropped EF Core's
SaveChanges/transaction for the storage action entirely, and the entity write was lost. A later
[Entity] load of that entity then found nothing.

This only affected sagas not persisted by EF Core; EF-Core-persisted sagas (the GH-3039 case)
were fine because their own provider IS EF Core.

Fix

Defer only when EF Core actually persists the saga:

if (chain is SagaChain saga && TryDetermineDbContextType(saga.SagaType, container) != null) return;

Otherwise fall through and apply EF Core's transaction support for the storage action as before. The
GH-3039 fix is preserved (EF-Core-persisted sagas still defer, honoring policy-set modes).

Tests

• Reproducing test Bug_3342_saga_entity_and_storage_action: a saga persisted by the SqlServer
  message store whose Start does Storage.Insert<OrderProcessRecord> and cascades a command whose
  handler loads that record via [Entity]. Fails on main (NRE — the inserted record is null),
  passes with the fix. Kafka-free (transports are local) and without OnException.Discard, so the real
  failure surfaces. The saga is [WolverineIgnore] + IncludeType so its unmapped storage action does
  not pollute sibling tests' conventional discovery.
• EF Core transactional middleware silently ignores TransactionMiddlewareMode.Eager for handler chains that return storage actions (Insert<T> / UnitOfWork<T> / Update<T>) #3039 regression suite (transaction_middleware_mode_tests) and the EFCore
  saga / storage-action / dbcontext-selection suites stay green (80 tests).

🤖 Generated with Claude Code