Compliance wave 2: EventProjection, auto-discovery and rebuild-cap suites (2.37.2)

[jeremydmiller]

Companion to marten#5118 (epic marten#5110, program marten#5119), and the follow-on to #607. Four more suites lifted out of the hand-mirrored Marten/Polecat pairs — 13 tests, taking the shared library from 42 to 55.

Suites added

Suite	What it pins down
AutoDiscoveredAggregateCompliance	A self-aggregating type with a generated evolver works with nothing registered. Distinct from SelfAggregatingEvolveCompliance, where the same aggregates are registered as inline snapshots and discovery is never exercised.
EventProjectionRegistrationCompliance	Document types discovered from a Store<T> call inside an explicit ApplyAsync override (marten#4166) and from a conventional Create return type, plus an end-to-end write proving the store really provisioned storage for a type nobody registered.
EventProjectionEnrichmentCompliance	EnrichEventsAsync runs before an inline EventProjection applies the same batch, and can read documents from the store while it does.
RebuildConcurrencyCapCompliance	Resolution of IEventStore.MaxConcurrentRebuildsPerDatabase (#420 / marten#4710): explicit setting wins, non-positive disables, otherwise pool size over eight with a floor of one, and the usage descriptor carries the effective value.

Strongest-assertion-wins in action: Marten's registration test only checked the store's known document types, Polecat's only checked PublishedTypes(). The shared suite does both and adds the round trip.

Seam additions

Each one exists because a suite needed it, not on speculation:

• EventStoreComplianceFixture.StoreDocument — seeding a lookup document the event store did not produce.
• EventStoreComplianceFixture.EventStore — store-level contracts (MaxConcurrentRebuildsPerDatabase, TryCreateUsage).
• EventStoreComplianceFixture.AllAggregateTypes — ProjectionGraph.AllAggregateTypes() is shared, but the graph hangs off each product's own options type.
• ComplianceStoreConfig.AddProjection + IComplianceStoreRegistrar.AddProjection.
• ComplianceStoreConfig.MaxConcurrentRebuildsPerDatabase / MaxPoolSize. These bypass the registrar deliberately: the products hang the cap off different objects (Marten Projections, Polecat DaemonSettings), and MaxPoolSize has to reach the connection string, which only the fixture owns.

Consumer-visible change

Consumers now supply three global aliases instead of one. The EventProjection suites declare projection types at file scope, so they cannot reach the <TOperations, TQuerySession> pair the suite classes are generic over:

global using ComplianceQuerySession = Marten.IQuerySession;
global using ComplianceOperations = Marten.IDocumentOperations;      // new
global using ComplianceEventProjection = Marten.Events.Projections.EventProjection;  // new

Aliases rather than a shared generic base, because both products' EventProjection carries store-specific members (Marten's IProjectionSchemaSource/IMartenRegistrable, Polecat's sealed storeEntity). README updated.

Landmine worth knowing

The generator's scan of ApplyAsync bodies for published types (AggregateAnalyzer.DiscoverDocumentTypesFromMethodBodies) is syntactic, so Store<T> must be written with an explicit type argument. Store(entity) compiles and silently registers nothing — that is a real trap for users, and it cost this PR one red test before the comment went in.

Verification

Both stores against the packed package: Marten 55/55, Polecat 55/55, still zero capability gates on either.

Consumer PRs: marten#5123, polecat#TBD — both blocked on the 2.37.2 publish.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde