Resolve discovered command and query extension points from the request scope

[woksin]

Fixed

• Start a Development application that uses a Chronicle command response value. Arc's discovered extension points were resolved from the root service provider, so a handler depending on the scoped IEventLog could not be created once the host turned scope validation on, and every such command threw. (Arc 21.1.0 cannot start a Development app that uses a Chronicle command response value: its own handler is resolved from the root provider but needs a scoped IEventLog #2505)
• Resolve command filters, command execution scopes and query filters from the scope the work runs in, so an implementation of any of these that depends on a scoped service works instead of throwing in Development. (Arc 21.1.0 cannot start a Development app that uses a Chronicle command response value: its own handler is resolved from the root provider but needs a scoped IEventLog #2505)

[woksin]

Reviewer context.

The mechanism is one step further down than #2505 describes. CommandResponseValueHandlers does not capture the handler instances at construction — InstancesOf<T>.GetEnumerator() calls _serviceProvider.GetService(type) on every enumeration. What it captures is the IServiceProvider. IInstancesOf<> is registered transient in Fundamentals (TypesServiceCollectionExtensions.cs:36), so it binds to whichever provider resolves it — and a singleton resolves it from the root. The failing stack confirms it:

System.InvalidOperationException: Cannot resolve '…HandlerNeedingAScopedCollaborator' from root provider
  because it requires scoped service '…ScopedCollaborator'.
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteValidator.ValidateResolution(…)
   at Cratis.Types.InstancesOf`1.GetEnumerator()+MoveNext()
   at Cratis.Arc.Commands.CommandResponseValueHandlers.CanHandle(…)

This matters for the choice of fix: it is not about when handlers are built, it is about which provider builds them.

Why resolve-per-invocation rather than a scoped registration. Making the collections scoped only moves the failure. CommandPipeline is a singleton — necessarily, it owns the IServiceScopeFactory that creates the scope a command runs in — and it takes ICommandFilters, ICommandResponseValueHandlers and ICommandHandlerProviders as constructor dependencies. A singleton consuming a scoped service is itself a captive dependency, so the container would reject that too. (CommandResponseValueHandlers is also registered twice — the explicit AddSingleton and the [Singleton] convention binding — so a lifetime change means changing both.)

Resolving from the scope at the point of use is what Arc already does everywhere else in this pipeline: TransactionalCommandScope, CommandProvideInvoker and CommandHandlerArgumentResolver are all [Singleton] and take the scoped provider per invocation, and IdentityEndpointMapper.cs:134 already resolves IInstancesOf<T> from RequestServices. The provider is the one CommandContext/QueryContext already carry, and the HTTP path supplies context.RequestServices. It falls back to the injected collection when there is no provider, which is why existing specs are untouched.

Audit of the siblings in CommandServiceCollectionExtensions, all confirmed by running them against a real Development host rather than by reading:

Collection	Verdict
ICommandResponseValueHandlers → ICommandResponseValueHandler	reproduced, fixed
ICommandFilters → ICommandFilter	reproduced, fixed — public extension point
CommandPipeline → ICommandExecutionScope	same shape, fixed — public extension point
ICommandHandlerProviders → ICommandHandlerProvider	reproduced, deliberately not fixed — see below
ICommandProvideInvoker, ICommandHandlerArgumentResolver	already correct; take the scoped provider per call

ICommandHandlerProvider fails the same way, but it is not the same defect. It builds the Type → ICommandHandler map once at startup, before any scope exists, and that map outlives every scope. A provider requiring a scoped service is a lifetime error in the implementation, not in Arc's registration — there is no correct scope to resolve it from. Left as is, deliberately.

Scope note — this PR also fixes QueryFilters, which is outside the issue. It is the identical shape (singleton holding IInstancesOf<IQueryFilter>, QueryContext already carrying the provider), and shipping the command-side fix alone would leave a Development app still throwing for a query filter with a scoped dependency. Say the word and I will split it out.

Verification. The four unit specs were run against the unfixed source: 9 of the 10 facts fail, and the host spec fails with the exception above. With the fix, all pass. Debug and Release builds clean with zero warnings on Arc.Core, Arc, Chronicle and the spec projects. Specs: Arc.Core.Specs 1925, Chronicle.Specs 632, Arc.Specs 274, MongoDB.Specs 192, Swagger.Specs 47, Testing.Specs 19, OpenApi.Specs 8 — 3,097 passing, 0 failing. The full-solution build could not run in this worktree because ProxyGenerator.Specs shells out to yarn build and the worktree has no node_modules; that is a worktree artifact and unrelated to the change — CI covers it.

Not verified: no Chronicle-backed application was started end to end against these bits. The host spec reproduces the exact container failure with a stand-in scoped service rather than the real IEventLog.