fix(handler-graphql): honour multiple: true on resolver dependencies

[adrians5j]

Split out of #5693 so it can be reviewed on its own — it is a fix to shared infrastructure, not part of that feature.

The bug

addResolver accepts the [abstraction, { multiple: true }] dependency tuple that the container uses everywhere else:

builder.addResolver({
    path: "Query.things",
    dependencies: [[Thing, { multiple: true }]],
    resolver: (things: Thing.Interface[]) => () => things.map(...)
});

It destructured the tuple, threw the options away, and single-resolved anyway. So the resolver above receives one object rather than an array, and dies on .map.

Why it is worth its own PR

The failure gives no hint where it came from. The GraphQL error is whatever the resolver did with the object — in our case e.map is not a function — attributed to the field, not to the builder. Anyone who tries the documented tuple form loses an afternoon to it.

Testing

Three tests in packages/handler-graphql/__tests__/GraphQLSchemaBuilder.test.ts: single resolution still works, multiple resolves every implementation, and an unregistered multiple dependency yields [] rather than undefined.

Reverting the one-line fix fails two of them with greeters.map is not a function, which is the production symptom exactly.

53 tests in handler-graphql, adio and lint clean.

Note for whoever merges

Independent of #5693. That PR originally needed this fix, but its listCapabilities resolver now goes through a use case and takes the multiple dependency via createImplementation, where it has always worked. The two can merge in either order.

Worth fixing regardless: the tuple form is what the Dependency type advertises, and the next person to use it in a resolver hits the same silent breakage.