Persist IEventStream<T> compound-handler appends without AutoApplyTransactions (#3032)

[jeremydmiller]

Closes #3032.

Problem

A compound handler that obtains an IEventStream<T> via the Load/LoadAsync convention (FetchForWriting<T>) and appends to it got no Marten transaction support unless opts.Policies.AutoApplyTransactions() was enabled — SaveChangesAsync was never generated and the appended events were silently dropped (no exception). This was inconsistent with the other handler-side Marten effects that self-persist: single/collection IMartenOp returns (fixed in #3025) and [AggregateHandler].

Fix

MartenOpPolicy now also detects a handler that takes an IEventStream<T> parameter (the append shape) and applies the same idempotent Marten transaction support it already applies for IMartenOp returns. ApplyTransactionSupport guards on CreateDocumentSessionFrame + DocumentSessionSaveChanges, so it composes with the aggregate workflow (which also uses IEventStream<T> via [WriteAggregate]) and with AutoApplyTransactions.

var appendsToEventStream = chain.HandlerCalls()
    .Any(call => call.Method.GetParameters().Any(p => p.ParameterType.Closes(typeof(IEventStream<>))));

Tests

New event_stream_append_persists — a compound handler (LoadAsync → FetchForWriting<T>, Handle appends) on a host without AutoApplyTransactions now persists the append (FetchStreamAsync count 1). Verified it fails (count 0, dropped) without the fix.

• Bug_225 (the AutoApplyTransactions-on compound path), the aggregate-handler workflow, and the single-IMartenOp suites stay green (94 targeted).
• Full MartenTests suite: 494/494.

No version bump — main is unpublished 6.4.4 (latest tag V6.4.1); rides the pending release.

🤖 Generated with Claude Code