Fix scheduled-cascade loss from [ReadAggregate]/[DocumentExists] handlers (closes #2941)

[jeremydmiller]

Closes #2941. Builds on @JurJean's repro from PR #2941 (test cherry-picked + extended).

The bug (verified)

A handler whose only Marten/Polecat dependency comes from an attribute - [ReadAggregate], [DocumentExists<T>], [DocumentDoesNotExist<T>] - silently lost any cascading DeliveryMessage<T>.DelayedFor(...) it emitted. Non-scheduled cascades from the same handlers were unaffected (they take Wolverine's in-memory delivery path), so the bug only surfaces when scheduling.

TrackedSession trace before the fix:

ScheduleViaReader     | 622 ms | ExecutionFinished
SomethingWasScheduled | 623 ms | Sent              ← recorded as Sent
ScheduleViaReader     | 626 ms | MessageSucceeded
                                  (never Received - 30s timeout)

The reporter saw it directly: StoreIncomingEnvelope shows up in the unit of work but is never saved.

Root cause (Wolverine side)

1. AutoApplyTransactions decides which IPersistenceFrameProvider to apply by calling CanApply, which queries chain.ServiceDependencies() for IDocumentSession.
2. Chain.serviceDependencies (src/Wolverine/Configuration/Chain.cs:276) only walks Middleware.OfType<MethodCall>() - other frame types are not inspected.
3. [ReadAggregate] injects FetchLatestAggregateFrame (AsyncFrame). [DocumentExists<T>]/[DocumentDoesNotExist<T>] inject DocumentExistenceCheckFrame (AsyncFrame). Both depend on IDocumentSession but neither is a MethodCall, so the dependency is invisible to ServiceDependencies.
4. WolverineParameterAttribute.Modify and ModifyChainAttribute.Modify both run lazily in HandlerChain.applyCustomizations - long after AutoApplyTransactions has evaluated CanApply. So self-declaring the dependency from inside Modify is too late.

Result: CanApply returns false, no DocumentSessionSaveChanges postprocessor is attached, and MartenEnvelopeTransaction.PersistIncomingAsync / its Polecat equivalent queue StoreIncoming(...) on the session that is never flushed.

[WriteAggregate] and [BoundaryModel] do not need this fix - their Modify() paths explicitly call ApplyTransactionSupport themselves (AggregateHandling.Apply line 43; BoundaryModelAttribute.cs:86). Saga chains hit the SagaChain short-circuit in CanApply.

Polecat side companion fix (shipped in Polecat 4.2.1)

Diagnosing this surfaced a second bug on the Polecat side: DocumentSessionBase.SaveChangesAsync early-returned when _workTracker.HasOutstandingWork() was false. _workTracker tracks document ops + event streams - it does NOT include ITransactionParticipants. Wolverine.Polecat's Session.StoreIncoming(...) adds a StoreIncomingEnvelopeParticipant whose BeforeCommitAsync writes the scheduled inbox row; if that's the only thing on the session (handler had no doc ops), SaveChangesAsync skipped the entire pipeline and the participant's BeforeCommitAsync never ran. Marten doesn't have this gap.

Fixed upstream in JasperFx/polecat#161, shipped as Polecat 4.2.1. This PR bumps the Polecat pin to 4.2.1 so the Wolverine-side CanApply fix actually closes the loop.

Fix (this PR, Wolverine side)

Direct attribute detection in MartenPersistenceFrameProvider.CanApply and PolecatPersistenceFrameProvider.CanApply. Walks handler-method parameters for [ReadAggregate], and handler-method / handler-type / message-type attributes for DocumentExistsAttribute<> / DocumentDoesNotExistAttribute<>. Detection works by reflection on existing handler metadata, so it does not depend on attribute Modify() having run yet.

Also bumps Polecat 4.1.1 → 4.2.1 in Directory.Packages.props to pick up polecat#161.

Tests + verification

Path	Test	Status
Marten [ReadAggregate]	Bug_aggregate_should_still_publish (cherry-picked from #2941; fixed the test bug of PublishReader missing from IncludeType)	local 6/6 pass; CI green
Marten [DocumentExists<T>]/[DocumentDoesNotExist<T>]	Bug_2941_document_exists_scheduled_cascade (new)	local 2/2 pass; negative-control 2/2 fail without the DocumentExists branch
Polecat [ReadAggregate]	Bug_2941_read_aggregate_scheduled_cascade (new)	exercised end-to-end on CI (was [Skip]'d in earlier commits pending polecat#161; unskipped now that Polecat 4.2.1 ships the upstream companion fix)
Polecat [DocumentExists<T>]/[DocumentDoesNotExist<T>]	Bug_2941_document_exists_scheduled_cascade (new)	same — unskipped now that 4.2.1 ships

Full Marten Bugs sweep: 45/45 pass. Full dotnet build wolverine.slnx -c Release clean (0 warnings, 0 errors).

Out of scope (follow-up worth tracking separately)

The IMartenDataRequirement / IPolecatDataRequirement return-value continuation strategies create MartenDataRequirementFrame / PolecatDataRequirementFrame (AsyncFrames using IDocumentSession) via a different code path - they are produced by *DataRequirementContinuationStrategy.TryFindContinuationHandler when a handler returns I*DataRequirement. The same scheduled-cascade-loss class could in theory occur there too; would want its own test scenarios in a follow-up.

🤖 Generated with Claude Code