Compliance suite: multi-stream projections

[jeremydmiller]

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

The library covers single-stream aggregation (self-aggregating evolve, string identity) and event projections (registration, enrichment). Multi-stream projections — the grouping/slicing half of the projection model — are untested cross-store, and they are the projections most likely to diverge, because slicing decides which shard sees which event.

ProjectionBase + ProjectionLifecycle and ComplianceStoreConfig.AddProjection(ProjectionBase, ProjectionLifecycle) are already in place. The concrete multi-stream base class is per-product, so this needs one global-alias addition in the same style the README already documents for ComplianceEventProjection and ComplianceStringPartyProjectionBase:

global using ComplianceMultiStreamProjectionBase =
    Marten.Events.Aggregation.MultiStreamProjection<Doc, TId>;   // Polecat: its own equivalent

What each store tests today

Marten	Polecat
Projections/MultiStreamProjections/*	Projections/multi_stream_projection_tests.cs
Projections/inline_aggregation_by_stream_with_multiples.cs	Projections/multi_stream_projection_stepthrough_tests.cs
Projections/hiearchy_projection.cs	Projections/time_based_multi_stream_projection_tests.cs
Aggregation/aggregates_should_be_registered_as_document_mappings_automatically.cs	Projections/aggregate_to_many_tests.cs

Scope

New MultiStreamProjectionCompliance suite:

1. Slice by a member of the event body — events from N streams land on one document
2. Slice by tenant / by a computed key
3. Fan-out: one event contributing to many slices (aggregate_to_many)
4. Inline vs async producing the same grouped result
5. An event type no slicer claims is skipped without failing the shard
6. Deleting a slice from within the projection

Deliberately out of scope here: sharded/partitioned execution and multi-node distribution — storage- and daemon-specific, stays in each repo.

Acceptance

• Suite enrolled in both stores; new alias documented in the package README alongside the existing four
• Originals retired for the absorbed behavior in both repos

[jeremydmiller]

Shipped — MultiStreamProjectionCompliance, 10 tests, both stores green

Marten 10/10, Polecat 10/10, no capability gates. Cost was exactly what this issue predicted: one global alias, ComplianceMultiStreamProjectionBase, in the same style as ComplianceStringPartyProjectionBase. No fixture member and no constructor shim — unlike the flat-table suite (#5147), both products' MultiStreamProjection<TDoc, TId> are parameterless subclasses of the shared JasperFxMultiStreamProjectionBase<TDoc, TId, TOperations, TQuerySession>, and every grouping construct the suite uses (Identity, Identities, FanOut) is declared on that shared base.

Coverage

• Identity — events from three separate streams landing on one aggregate; events within one stream splitting across two aggregates; two identities staying independent; a later commit updating an aggregate an earlier one built
• Identities — one event reaching every identity it names
• FanOut — children applied inside the parent's slice; a fanned-out child composing with ordinary events on the same aggregate
• An identity no event names having no aggregate at all
• Async lifecycle agreeing with inline
• Rebuild reproducing the grouping, applying each event exactly once

Grouping is asserted through the persisted document rather than by re-folding, so a projection that sliced correctly but never wrote fails.

One thing worth recording for the next fan-out test

FanOut does not route by the child's own identity. The parent carries the identity and the child is applied inside whatever slice the parent landed in — so a child type needs no Identity registration, and giving it one is actively wrong.

An earlier draft of this suite modelled it the other way round (child carrying a Department, parent carrying none) and produced no aggregate at all on Marten. That read like a product bug for about a minute. It was not: DayProjection in DaemonTests/Aggregations/multi_stream_projections.cs:270 and the docs both show the parent holding the identity. The suite now says so in a comment at the registration site.

Closes #5145.