v1/query backend returns 200 OK and empty list instead of a 403 when wrong token given

#### Feature Description

When using the API to get a list of prepared queries, if you are using a token that lacks permissions to return the list of prepared queries, give a 403 error instead of a 200 OK and an empty list.

#### Use Case(s)

Currently, it is not possible to use the `consul` command to list prepared queries, and the documentation recommends using the API directly. It's not unexpected that someone would use `curl` to check the endpoint of this. However, if a valid token is not passed, the result is a 200 OK with an empty list, which can be quite confusing.

For example:

```
$ curl http://localhost:8500/v1/query -i
HTTP/1.1 200 OK
Content-Type: application/json
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
X-Consul-Effective-Consistency: leader
X-Consul-Index: 27769289
X-Consul-Knownleader: true
X-Consul-Lastcontact: 0
X-Consul-Query-Backend: blocking-query
Date: Mon, 14 Feb 2022 11:04:01 GMT
Content-Length: 2

[]
```

```
$ curl --header "X-Consul-Token: $TOKEN" http://consul:8500/v1/query -i
HTTP/1.1 200 OK
Content-Type: application/json
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
X-Consul-Effective-Consistency: leader
X-Consul-Index: 27769289
X-Consul-Knownleader: true
X-Consul-Lastcontact: 0
X-Consul-Query-Backend: blocking-query
Date: Mon, 14 Feb 2022 11:04:54 GMT
Content-Length: 455

[{"ID":"..." (data here)
```

Start by reproducing the unauthenticated and token-authenticated curl requests against the /v1/query endpoint and compare their responses. Trace the endpoint's permission handling, then verify that a token lacking permission returns 403 while an authorized request still returns the prepared-query list.

Written by the indexing model from the issue text.