More broadly, I dislike the characterization of the web browser as the "client" in this situation. After all, the browser isn't the recipient of the remote host's services: it's just the messenger or agent on behalf of the (typically human) user, who is the real client of the server, and the recipient of the hypermedia it offers via a hypertext protocol.
That is, the browser may be communicating with the remote server (using APIs provided by the local OS), but it is not itself interfacing with the server, i.e., being offered a service for its own benefit. It may possibly be said that the whole system of "user + browser" interfaces with the remote server, but then it is no longer an application.
(Of course, this is all assuming the classical model of HTML web pages presented to the user as-is. With JS, we can have scripts and browser extensions acting for their own purposes, so that they may be rightly considered "client" programs. But none of these are using a REST API in Fielding's sense.)
OK, i understand you dislike it. But by any reasonable standard the web is a client/server distributed system, where the browsers are the clients. I understand you don't feel like that's right, but objectively that's what is going on. The browser is interfacing with the remote server, via an API discovered in the hypertext responses, based on actions taken by the users. It is no different than, for example, a MMORPG connecting to an API based on user actions in the game except that the actions are discovered in the hypertext responses. That's the crux of the uniform interface of REST.
I don't know what "for its own benefit" means.