Lift CompactStreamAsync<T> onto the shared operations surface, then a stream-compacting compliance suite

[jeremydmiller]

Part of #5118 (compliance wave growth), epic #5110. Cross-repo: the first half targets jasperfx.

Stream compacting is implemented in both products with the same signature over the same shared request type, but declared on each product's own operations interface rather than on JasperFx's:

	Declaration
shared today	JasperFx.Events/Protected/StreamCompactingRequest.cs:71 — StreamCompactingRequest<T> is already a JasperFx type
Marten	Marten.Events.IEventStoreOperations.CompactStreamAsync<T>(Guid|string, Action<StreamCompactingRequest<T>>?) (Marten/Events/EventStore.StreamCompacting.cs:35)
Polecat	Polecat.Events.IEventOperations.CompactStreamAsync<T>(Guid|string, Action<StreamCompactingRequest<T>>?) (Polecat/Events/IEventOperations.cs:61)

JasperFx.Events.IEventStore.CompactStreamAsync(Guid\|string, CancellationToken) exists but is the store-level, non-generic, no-configuration form — and on Marten both overloads reflect back onto the generic method rather than being the real entry point. It is not what the tests exercise.

Part 1 (jasperfx): lift the generic method

Declare CompactStreamAsync<T>(Guid id, Action<StreamCompactingRequest<T>>? configure = null) and the string overload on the shared JasperFx.Events.IEventStoreOperations. Both products already have the exact signature, so adoption is deleting a declaration, not writing an implementation. Confirm this is additive on both sides before shipping — it is a source-breaking change if either product's method differs in optionality or return type.

Part 2 (compliance): the suite

Once the method is shared, StreamCompactingCompliance is portable with no fixture change.

Marten tests today	Polecat tests today
Aggregation/stream_compacting.cs	Events/stream_compacting_tests.cs

1. Compacting collapses events below the compaction point into a snapshot event and leaves the aggregate's folded state unchanged
2. AggregateStreamAsync after compaction equals the pre-compaction result
3. FetchStreamAsync returns the compacted shape; FetchStreamStateAsync still reports the true version
4. Compacting an already-compacted stream
5. Compacting a stream with an inline snapshot registered keeps the document consistent
6. Guid and string stream identity

Acceptance

• jasperfx: method lifted, JasperFxVersion bumped in the same PR (the --skip-duplicate publish trap), both products adopt
• Suite enrolled in both stores; originals retired in both repos

[jeremydmiller]

First half done — the lift merged in #635, publishing as 2.41.0

CompactStreamAsync<T> onto JasperFx.Events.IEventStoreOperations, as default-implemented members that throw rather than abstract ones — so a store without compacting stays source-compatible. That matters for the Sqlite consumer (#5156), which will not have compacting on day one.

⚠️ Adoption cannot lag the bump. Both products' operations interfaces already inherit JasperFx.Events.IEventStoreOperations while also declaring CompactStreamAsync<T> themselves, so on bumping to 2.41.0 the same signature is reachable through two paths and call sites go ambiguous (CS0121). Adopting means deleting the per-product declarations — which is the point of the lift — but it has to land in the same step. Polecat already carries the same diamond on FetchLatest and collapses it with new if a softer landing is wanted.

Still outstanding on this issue

The compliance suite this lift exists to enable. That is the second half of the issue's scope and is not built yet — it needs the consumers on 2.41.0 first, since the suite has to call the lifted member through the shared interface.

Leaving this open until the suite ships and is enrolled in both stores.

[jeremydmiller]

Second half built — StreamCompactingCompliance, 11 tests, in #639 (2.43.0)

Zero seam cost, which is the direct payoff of the lift: CompactStreamAsync<T> is reached through the shared IEventStoreOperations, so the suite needed no fixture member, no alias and no config addition. Nothing else in the backlog has come in that cheap.

Shape

Compacting is meant to be invisible from the read side, so every test pairs a storage assertion (how many events survive, what the survivor is) with a behavioural one (what the stream still aggregates to). A store that drops the folded state, or folds it and then loses events it should have kept, fails the second half while passing the first.

Covered: compact-at-latest, compact-at-version with the later events surviving untouched, idempotency, the no-op on a stream that does not exist, appending afterwards, the archiver callback receiving exactly the events about to be replaced, and the string-identified stream.

The assertion most likely to have caught drift

Version preservation. Compacting is destructive to rows but must not rewind the stream: after compacting a nine-event stream the version is still nine, and the surviving Compacted<T> is stamped with nine rather than one.

Only Marten's own tests pinned that. Polecat's compact_stream_preserves_stream_version — despite the name — asserts only that appending afterwards still works, which passes vacuously if the version rewound and then climbed again. Now pinned for both.

Deliberately out of scope

The Timestamp cut-off on the request. Deriving one that actually discriminates needs two commits with server-side timestamps far enough apart to order reliably on a CI host that is not the database host, and the version cut-off already covers partial compaction deterministically.

Notes for the adoption

IEventsArchiver<TOperations> is generic over the consuming product's operations type, so the recording stub is a nested private class inside the suite — it can close the generic over the suite's own TOperations. That works because the request carries the non-generic IEventsArchiver marker and each product downcasts at execution time.

The string half needs its own aggregate with a string Id (ComplianceStringMeter). Registering a Guid-keyed document in an AsString store is an InvalidProjectionException at store construction on both products, not a runtime surprise.

Marten: 11/11. Closes when both consumers have enrolled it.