MapModule<T>(): resolve unregistered modules via ActivatorUtilities

[carldebilly]

Summary

• ResolveModuleFromServices<T>() used GetService<T>(), which only resolved types explicitly registered in the DI container. Callers of MapModule<T>() had to pre-register their module or get an InvalidOperationException.
• Switch to ActivatorUtilities.GetServiceOrCreateInstance<T>() so modules with a parameterless constructor — or constructor dependencies already in the container — resolve without explicit registration.
• This makes MapModule<T>() a true first-class composition path alongside MapModule(new T()), enabling constructor injection in modules.

Motivation

Without this fix, the only way to use MapModule<T>() was to manually register the module type in the service collection. This defeated the purpose of the generic overload — callers ended up using MapModule(new MyModule()) instead, which bypasses DI entirely and forces [FromServices] on every handler parameter.

With this fix, a module like:

class SessionModule(SessionManager manager, ViewerRegistry viewers) : IReplModule { ... }

resolves naturally via app.MapModule<SessionModule>() as long as SessionManager and ViewerRegistry are registered — no module registration needed.

Changes

File	What
IReplApp.cs	Add [DynamicallyAccessedMembers] on MapModule<T>() generic parameter
ReplApp.cs	ResolveModuleFromServices<T>() → ActivatorUtilities.GetServiceOrCreateInstance<T>() with trim annotations

Test plan

• Existing Given_ModuleComposition tests pass (7/7) — validates both registered and unregistered module resolution
• Full integration test suite passes (382/382)

---