Compliance suite: subscriptions

[jeremydmiller]

Part of #5118 (compliance wave growth), epic #5110.

Subscriptions — raw event delivery to user code off the daemon, with checkpointing — are a first-class JasperFx.Events concept (ISubscriptionSource<TOperations, TQuerySession>, JasperFxSubscriptionBase, ISubscriptionController, SubscriptionAgent), implemented and tested in both products, and untested cross-store.

The subscription base is generic over the same <TOperations, TQuerySession> pair the compliance fixture is already generic over, so a compliance subscription can be declared directly in the shared source with no alias gymnastics — this is one of the cleaner ports left.

Seam additions required

1. ComplianceStoreConfig.AddSubscription(...) on the config + IComplianceStoreRegistrar — both products register subscriptions through their own options object, so this follows the existing AddProjection pattern exactly.
2. Nothing else — driving and asserting runs through IProjectionDaemon and the shared controller interfaces the fixture already exposes.

What each store tests today

Marten	Polecat
DaemonTests subscription tests (incl. subscription_registrations_through_host, subscribe_from_present)	Subscriptions/subscription_tests.cs
EventSourcingTests subscription registration tests	Daemon/projection_coordinator_disabled_mode_tests.cs (partial)

Scope

New SubscriptionCompliance suite:

1. A registered subscription receives every appended event exactly once, in sequence order
2. Checkpointing: stop the daemon mid-stream, restart, and delivery resumes without replay or gaps
3. Event-type filtering on the subscription only delivers the filtered types
4. Subscribe-from-present skips pre-existing events; subscribe-from-beginning does not
5. A subscription that throws follows the same dead-letter/skip contract as a projection (cross-check against the dead-letter suite; assert the shared half only)
6. The subscription's own session participates in the same unit of work as the events it processes

Acceptance

• One registrar addition; suite enrolled in both stores
• Originals retired for the absorbed behavior in both repos

[jeremydmiller]

Cost correction — this needs three aliases, not zero

This issue says the subscription base "is generic over the same <TOperations, TQuerySession> pair the compliance fixture is already generic over, so a compliance subscription can be declared directly in the shared source with no alias gymnastics — this is one of the cleaner ports left."

That is true of JasperFxSubscriptionBase, but it is not the type a subscription has to be to get registered. Checked before starting work:

The only public registration path takes each product's own ISubscription

	Signature
Marten	ProjectionOptions.Subscribe(Marten.Subscriptions.ISubscription, Action<ISubscriptionOptions>?) (ProjectionOptions.cs:249)
Polecat	PolecatProjectionOptions.Subscribe(Polecat.Subscriptions.ISubscription, Action<ISubscriptionOptions>?) (PolecatProjectionOptions.cs:142)

Both bodies do subscription as ISubscriptionSource<TOperations, TQuerySession> ?? new SubscriptionWrapper(subscription) — so the shared generic is preferred internally, but there is no public overload accepting it. registerSubscription is private in both. A shared subscription must therefore implement the product's ISubscription, which shared source cannot name without an alias.

Three aliases, because all three types in the signature are per-product

Both interfaces declare an identical method:

Task<IChangeListener> ProcessEventsAsync(
    EventRange page, ISubscriptionController controller, IDocumentOperations operations, CancellationToken ct);

EventRange and ISubscriptionController are JasperFx-shared. The other three are not:

1. ISubscription — Marten.Subscriptions.ISubscription vs Polecat.Subscriptions.ISubscription
2. IDocumentOperations — Marten.IDocumentOperations vs Polecat.IDocumentOperations. Note this is not the existing ComplianceOperations alias: Polecat's compliance TOperations is IDocumentSession, and although IDocumentSession : IDocumentOperations, implementing an interface method requires the exact declared parameter type.
3. IChangeListener — Marten/IDocumentSessionListener.cs:29 vs Polecat/IChangeListener.cs:10

So the consumer alias count goes 5 → 8 for this one suite.

Not a blocker, just a re-rank

The suite is still worth building and the mechanics are understood — this is the same misclassification #5147 had, where the stated cost was the smaller half of the real one. Recording it so the "cleaner ports left" framing does not survive into planning.

Cheaper alternative worth considering first: a public Subscribe(ISubscriptionSource<TOperations, TQuerySession>, ...) overload on both products would let the shared source use JasperFxSubscriptionBase directly and drop all three aliases. That is an additive upstream-ish change in two products rather than three aliases in every consumer forever — and it would pay off again for the Sqlite consumer (#5156). Same shape of trade as #5153/#5154.