Disclaimer: this is based on what I've read, not on direct personal experience with GraphQL.
It looks like the term "resolver" is associated with GraphQL (at least in the context of your question), where it has to do with resolving the specification represented by the query into an actual data structure (it figures out how to make the data have a concrete shape, and fill it with values). That is, for each field specified in the query, there's a function that figures out how to resolve that specific field. Each field-specific function is termed a resolver. And then there's some mechanism that calls the corresponding resolvers recursively for each field, until you hit simple (non-composite, scalar) values.
"Each field on each type is backed by a function called the resolver
which is provided by the GraphQL server developer. When a field is
executed, the corresponding resolver is called to produce the next
If a field produces a scalar value like a string or number, then the
execution completes. However if a field produces an object value then
the query will contain another selection of fields which apply to that
object. This continues until scalar values are reached. GraphQL
queries always end at scalar values." (source)
So, resolvers are not specifically concerned with handling the web request itself, they have a more narrowly defined job.
Some more context
In a web app, or a web service, a controller is (more or less) an entry point for a request. A controller can (and often does) call other stuff to handle the details of the request. That is, it orchestrates other objects and functions that have narrower responsibilities, and that collaborate together to fulfill the request. That's just the normal responsibility segregation (i.e. as soon as your logic becomes nontrivial, you don't want to write all of it in the same function on the controller).
With GraphQL (or any query-based approach), you can replace all endpoints that allow callers to request data in a predefined way (or some subset of such endpoints), with a single endpoint that accepts a user-provided query, which allows them to specify exactly what they want. The query itself plays the same role that URL parameters or request body did in a traditional Web APIs (the query is a form of input), it's just that's it's more powerful, because it's a language of sorts.
So, with a query-based approach, you can have a single entry point - a single controller - that, among other things, calls some resolver to ask it to interpret/resolve the query (or a part of it) into an actual data structure. Maybe it orchestrates which resolver is called when, or how the data is combined into the final result (not sure about the details in the GraphQL case). You could in principle do extra stuff before and/or after you call the resolver(s) (like authorization, query extraction/parsing, or field censoring, or something), and then return the response to the client. And you could implement all this manually.
I'm guessing that in various frameworks that have support for GraphQL, the presence of the controller (or whatever internal system takes on its role) and other supporting systems is not obvious (as in, the framework might handle all the controller-y details for you, and call the resolver(s) for you) - so I'm guessing that this is the source of your confusion.
So, to summarize: to me, it looks like the conceptual responsibility of the resolver isn't to respond to the request, but to figure out how to transform the data, as it exist in some storage or data source, into the user-specified shape (the data format that the user wants). When you think about it, you could have a similar concept without having a client/server architecture (you could have a scenario where you query your own local data, without going over the web, so the concept itself is not fundamentally web-related).