Marten#4472: Modular composite configuration smoke + behavior tests across satellite assemblies

[jeremydmiller]

Summary

Closes #4472.

Pre-9.0 audit gap: the monolithic services.AddMarten(opts => { ... }) case is well-tested, but the multi-assembly modular case — projection types declared in satellite assemblies (each carrying [assembly: JasperFxAssembly]), each contributing its own IConfigureMarten that references its local projections, composed into a main host via DI — was never explicitly validated against the post-#276 (SG-only dispatch) + post-#4461 (zero-runtime-codegen) contracts.

This PR adds the regression-gate fixture, the supporting Nuke + CI wiring, and a new docs page.

Three new isolated test projects

Project	Role
src/ModularConfigTests.SatelliteA/	Order aggregate (Guid Id), OrderPlaced/OrderShipped events, partial OrderProjection : SingleStreamProjection<Order, Guid>, OrdersConfig : IConfigureMarten. [assembly: JasperFxAssembly]. SG analyzer wired locally.
src/ModularConfigTests.SatelliteB/	Daily aggregate (string Id), DailyOpened/DailyClosed events, partial DailyProjection : MultiStreamProjection<Daily, string> with date-keyed identity, ReportingConfig : IAsyncConfigureMarten. Same JasperFxAssembly + SG analyzer wiring.
src/ModularConfigTests/	Test harness — headline smoke test plus four pin tests, one per locked-in design contract.

The satellites are deliberately isolated from CoreTests / DaemonTests / EventSourcingTests. Each test fixture builds a fresh host with a unique per-test schema name.

Locked-in design contracts (pinned by the four tests)

1. OrderingTests — registration-order = invocation-order; last-registered IConfigureMarten wins on scalar setter contention.
2. LastWinsTests — duplicate event-type registration is idempotent (no throw); last-registered scalar setter wins.
3. AddMartenTimingTests — IConfigureMarten registered AFTER services.AddMarten(...) still applies. The StoreOptions factory resolves IEnumerable<IConfigureMarten> at store-build time from the final DI snapshot.
4. AsyncComposeTests — IConfigureMarten (sync) + IAsyncConfigureMarten (async) compose; both contributions land on the final StoreOptions.

Critical finding surfaced during the work — filed upstream as #4494

A bare services.AddSingleton<IAsyncConfigureMarten, MyAsyncConfig>() registration adds the implementation to DI but never invokes its Configure() method. The hosted service that drains async configs (AsyncConfigureMartenApplication) is only registered as a side effect of services.ConfigureMartenWithServices<T>(). The chip's smoke-test snippet used the bare AddSingleton; the fixture uses the correct extension API and the docs page calls the asymmetry out explicitly. UX gap tracked at #4494.

Wired into the build / CI

• src/Marten.slnx registers the three new projects under /Testing/.
• build/build.cs gains a TestModularConfig Nuke target, added to the Test aggregate's .DependsOn(...) chain after TestEventSourcing.
• All four main CI workflows get a test-modular-config step:
  • on-push-do-ci-build-pg15-jsonnet-eventsourcing.yml (after test-event-sourcing)
  • on-push-do-ci-build-pgLatest-systemtextjson-eventsourcing.yml (after test-event-sourcing)
  • on-push-do-ci-build-pg15-jsonnet.yml (after test-document-db)
  • on-push-do-ci-build-pgLatest-systemtextjson.yml (after test-document-db)
• .nuke/build.schema.json regenerated to include the new target. Also drops the stale TestCodeGen entry that was orphaned from build.cs — auto-regenerated cleanup unrelated to this PR's scope but cheaper to include than to leave drifted.

Docs

docs/configuration/composite-configuration.md (new) covers:

• The composite-config pattern with a worked example linking back to the regression fixture
• The four locked-in design contracts
• The [assembly: JasperFxAssembly] marker rationale (it's NOT a filter for DiscoverGeneratedEvolvers; the marker is for forward-compat with other Critter Stack scanning surfaces)
• Required satellite-assembly setup (partial projection classes + analyzer-only JasperFx.Events.SourceGenerator PackageReference)
• The IConfigureMarten vs IAsyncConfigureMarten registration asymmetry (AddSingleton<IAsyncConfigureMarten>() silently never runs — hosted service only wired via ConfigureMartenWithServices<T>() #4494)

Page added to the VitePress sidebar under Configuration.

Test plan

• ./build.sh test-modular-config succeeds locally
• All 5 tests pass on net9.0 and net10.0 (1 smoke + 4 pin tests)
• dotnet build src/Marten.slnx -c Release clean
• markdownlint clean on the new docs page

Out of scope

• NuGet-package-distribution scenario (satellite as .nupkg consumed by downstream) — explicit follow-up if the smoke test surfaces concerns.
• TypeLoadMode.Static variant of the smoke test — the chip's smoke test uses TypeLoadMode.Auto; static-mode could be a follow-up.
• Refactoring IConfigureMarten / IAsyncConfigureMarten themselves.

🤖 Generated with Claude Code