Resolve default lazy values in Execution::Next

[ydah]

Schema.resolves_lazies? currently assumes that the first two entries in lazy_methods don't require lazy handling:

lazy_method_count > 2

Those entries are the default handlers for GraphQL::Execution::Lazy and GraphQL::Dataloader::Request. As a result, Execution::Next skips lazy detection on schemas without an additional lazy_resolve registration.

For example, returning a GraphQL::Dataloader::Request produces its object representation instead of the loaded value:

context.dataloader.with(NumSource).request(1)
# => "#<GraphQL::Dataloader::Request:...>"

The count is also unstable because LazyMethodMap caches subclass lookups in the same storage. Resolving a subclass of a registered lazy type adds another entry and can change resolves_lazies? from false to true based on execution history.

This PR treats any non-nil lazy method registration, including the default registrations, as enabling lazy resolution. Cached subclass lookups can no longer change the result because a non-nil subclass cache entry requires an existing non-nil superclass registration.

[rmosolgo]

I don't want to support returning Request instances. AFAIK calling .load is always just as good. Is there a reason to continue supporting them?

If we don't support returned Requests, is this PR still needed?

[ydah]

@rmosolgo Thanks, that makes sense.

I found this while testing a resolver that returned .request(...), but I don't have a case where returning the request is preferable to calling .load. I also confirmed that this path is already deprecated through load_with_deprecation_warning.

Without supporting returned Request instances, the user-visible fix in this PR isn't needed. The cache-dependent resolves_lazies? behavior is real, but custom lazy_resolve registrations already enable lazy handling before cached subclass entries matter.

I'll close this PR.