Eliminate ExtensionLoader assembly scanning via source-generated extension manifest (GH-2902)

[jeremydmiller]

Closes #2902.

What

Replaces Wolverine's runtime assembly scan for IWolverineExtension types with the compile-time extension manifest from JasperFx (jasperfx#371), and removes ExtensionLoader entirely. Startup no longer probes the application's bin directory (AssemblyFinder.FindAssemblies) or speculatively Assembly.Loads candidates.

Changes

• IWolverineExtension : IJasperFxExtension (and IAsyncWolverineExtension too) so implementers are seen by the generator's marker scan.
• JasperFx.SourceGenerator flows transitively from the WolverineFx package (PrivateAssets="none"), so the app's own assembly and every extension/transport assembly emit a JasperFx.Generated.DiscoveredExtensions manifest. The generator self-gates to eligible assemblies ([JasperFxAssembly]/[WolverineModule]-marked or executable), so it is a no-op where it has nothing to emit.
• ExtensionLoader deleted. New WolverineOptions.DiscoverAndApplyExtensions() reads the manifest from loaded assemblies and applies extensions early (while the IServiceCollection is still mutable, matching historical timing).
• [WolverineModule] assemblies are still added to handler discovery via IncludeExtensionAssemblies (covers pure handler modules like OrderExtension that declare a bare [assembly: WolverineModule] and emit no manifest entry).

Two design points worth a look

1. Discovery is scoped to each assembly's declared [WolverineModule<T>] type — not every IWolverineExtension the marker scan lists. The manifest's marker scan also picks up framework-internal helpers in the [JasperFxAssembly]-marked core (DisableExternalTransports, DisablePersistence, UseSoloDurabilityMode, the ConfigureWolverine lambda extension). Those are applied explicitly/via DI and must never be auto-activated — auto-applying DisableExternalTransports would stub every transport, and LambdaWolverineExtension has no parameterless ctor. Gating on the declaring assembly's declared module type reproduces the exact set the old scan applied.

2. Reference-graph module loading instead of the bin-directory glob. The manifest reader only sees loaded assemblies, but a referenced module (e.g. WolverineFx.RuntimeCompilation) may not be loaded at bootstrap. Discovery first walks the application's reference graph (Assembly.GetReferencedAssemblies, skipping framework prefixes) and loads the [WolverineModule] assemblies it reaches — not the old Directory.EnumerateFiles probe — so "reference the package and it auto-activates" still works.

Acceptance criteria

• IWolverineExtension extends IJasperFxExtension; extensions discovered via the generated manifest are applied identically to today (same set, same Configure ordering/idempotency).
• No AssemblyFinder.FindAssemblies bin-directory probe on startup.
• The JasperFx.SourceGenerator analyzer is referenced so app + extension assemblies emit manifests.
• AOT/trim: the [RequiresUnreferencedCode] AssemblyFinder scan is gone from the extension path.
• Regression coverage for modular-monolith / multi-extension-assembly discovery (extension_discovery_via_manifest, plus the existing Module1/OrderExtension/RuntimeCompilation fixtures via the default-app suites).

Verification

• Full wolverine.slnx Release build: 0 warnings / 0 errors.
• All 1713 CoreTests pass (net9.0).

🤖 Generated with Claude Code

[jeremydmiller]

Brought the branch up to date with main and fixed the CI failures.

Note on history: branch protection blocks force-push, so I merged main in (commit 21280ef) rather than rebasing.

CI failure root cause: every failing suite (e.g. MessageRoutingTests) threw no IAssemblyGenerator (Roslyn) is registered. WolverineFx.RuntimeCompilation is referenced for its [WolverineModule] auto-activation but its types are never used directly, so the C# compiler prunes it from assembly metadata — the reference-graph walk (Assembly.GetReferencedAssemblies) couldn't see it even though it's deployed, so its DiscoveredExtensions manifest was never read. (This would affect real reference-and-auto-activate apps too, not just tests.)

Fix (a0bd68c): load the non-framework assemblies from the runtime's resolved deployment list (TRUSTED_PLATFORM_ASSEMBLIES), which includes pruned-but-deployed assemblies. Still not the old Directory.EnumerateFiles bin probe — it reads the runtime's own assembly list. The reference-graph walk remains as a fallback for hosts that don't surface that list (single-file deployments).

Validated locally: previously-failing MessageRoutingTests (25) now pass, CoreTests (1713) pass, full wolverine.slnx Release build clean.