GH-4238: DataAnnotations validation must not trip the user's ServiceLocationPolicy

[jeremydmiller]

Closes #4238.

The DataAnnotations validation middleware could not be used together with
ServiceLocationPolicy.NotAllowed -- the Wolverine 6 default. The application threw
InvalidServiceLocationException at bootstrap and could not start at all:

Found service locations while generating code for POST_bug4238_validate, but
ServiceLocationPolicy.NotAllowed is in effect.

Why

This is fallout from GH-4171, already on main. That change deliberately removed IServiceProvider
from the derived HttpContext variables so it would stop being answered silently out of
httpContext.RequestServices no matter what ServiceProviderSource said, and would instead go
through the normal service-variable machinery -- where it is reported to ServiceLocationPolicy.
Right for user code. But DataAnnotationsHttpValidationExecutor.Validate takes an
IServiceProvider so it can build the ValidationContext, so Wolverine's own middleware began
being reported as a service location inside the user's chain.

The fix

The policy supplies that argument itself via TrySetArgument rather than leaving the codegen to
source it, bound to httpContext.RequestServices.

RequestServices is the right provider here regardless of ServiceProviderSource. The only thing
the ValidationContext's provider ever does is answer GetService for a ValidationAttribute or an
IValidatableObject; it runs against the inbound request before any handler scope is relevant; and
it is the same provider ASP.NET Core's own model validation hands to a ValidationContext. Routing
it through IWolverineRuntime, as the issue suggested, would add an indirection to arrive in the
same place.

Tests

Bug_4238_dataannotations_with_service_location_not_allowed bootstraps an endpoint carrying
DataAnnotations under NotAllowed and exercises both the invalid (400) and valid paths. Before the
fix it threw at bootstrap, so neither was reachable. A second test pins AlwaysAllowed, which was
never broken and must stay unbroken.

Full Wolverine.Http.Tests: 1017 passed, 10 skipped. The one failure in that run,
use_cascaded_messages_with_http, reproduces on clean main without this change -- and a different
method in that same class fails from run to run, so it is a pre-existing tracked-session bleed in
that class rather than anything here.

🤖 Generated with Claude Code