Adopt compliance wave 2: retire four more mirrored Marten test pairs

[jeremydmiller]

Polecat's half of compliance wave 2. Companion to marten#5118 / marten#5123 (merged), on JasperFx.Events.ComplianceTests 2.37.2 (JasperFx/jasperfx#608, published). Same trade #393 made for the first four pairs.

Retired here

Deleted	Replaced by
Events/auto_discover_aggregate_types.cs	AutoDiscoveredAggregateCompliance
Projections/event_projection_should_register_document_types.cs	EventProjectionRegistrationCompliance
Projections/event_projection_enrichment_tests.cs	EventProjectionEnrichmentCompliance
rebuild_concurrency_cap_resolution.cs	RebuildConcurrencyCapCompliance

Coverage went up on both sides of the port

• Registration: Polecat's copy asserted only PublishedTypes(); Marten's asserted only its own known-document-types list. The shared suite asserts both routes and adds an end-to-end append proving the store really provisioned storage for a document type nobody registered — the actual point of marten#4166.
• Rebuild cap: Polecat's copy was a pure unit test against a dummy connection string. The shared one builds a real store, so the pool-size-derived default is exercised against a real SqlConnectionStringBuilder round trip.

Fixture additions

PolecatComplianceFixture gains the seam members the new suites need — StoreDocument, EventStore, AllAggregateTypes, an AddProjection registrar member, and connection-string / DaemonSettings handling for the rebuild-cap knobs. The alias file gains ComplianceOperations and ComplianceEventProjection beside the existing ComplianceQuerySession, because the EventProjection suites declare projection types at file scope and cannot reach the suite's generics.

CLAUDE.md

Documents that Polecat test runs must never overlap. The suite isolates by DatabaseSchemaName inside one shared master database, so a second concurrent run — including one left alive after its parent shell was killed — produces a large, scattered failure set across unrelated areas that reads exactly like a real regression. That cost real time while preparing this PR.

Results, stated honestly

• Compliance namespace: 55/55, no capability gates, against the published 2.37.2.
• Full suite: 1635 passed / 1 failed / 3 skipped.

The single failure is not from this change, and it was a different test on each of two consecutive clean runs:

1. single_tenant_has_no_tenant_id_column_tests.full_lifecycle_works_without_tenant_id_column — the pre-existing isolation defect filed as IntegrationContext.StoreOptions leaves documents behind, so some tests only pass on a fresh database #398 (IntegrationContext.StoreOptions never deletes data, so the schema accumulates rows across runs). Cleared the residue and it passed.
2. operation_dependency_tests.store_multiple_types_with_events_all_committed — events1.Count should be 2 but was 0 on freshly-generated stream ids. Passes 4/4 when its class runs alone.

Two consecutive full runs, each with exactly one failure, in different untouched classes, both green in isolation. I do not have a cause. My first guess was intra-suite parallelism, and that is wrong — src/Polecat.Tests/xunit.runner.json sets parallelizeTestCollections: false, so collections are serialized and nothing inside the run is concurrent. That rules out the obvious explanation for FetchStreamAsync returning 0 events for a stream written in the same test, and leaves this genuinely unexplained.

Worth its own investigation; I did not chase it here because it is orthogonal to this change. CI runs on a fresh instance and should be green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde