### Elasticsearch Version

latest

### Installed Plugins

_No response_

### Java Version

18.0.1.1

### OS Version

Linux 5.17.6-1-MANJARO

### Problem Description

We created a `hasData` service which utilizes the `resolve_index` api to check whether ES data exists. When making a call to `internal/index-pattern-management/resolve_index` to query whether data exists or not, in certain scenarios it fails with a 500 Internal Server Error.

The ES error being - 

> security_exception: [security_exception] Reason: action [indices:admin/resolve/index] is unauthorized for user [test_user] with roles [test_dashboard_user,reporting_user], this
action is granted by the index privileges [view_index_metadata,manage,all]

The scenarios being:
Scenario one:
1. There are 3 indices
2. User has `read` access to 1 of the indices, but not to the other two
3. The call fails with a 500 Internal Server Error. The user should be able to see the index they have access to.

Scenario two:
1. This refers to a scenario where the user has `read` access to the index, but `no view_index_metadata` privileges.

Original issue ticket in Kibana for reference - [#132478](https://github.com/elastic/kibana/issues/132478)

### Steps to Reproduce

The user has `read` access to the index, but `no view_index_metadata` privileges.
The api fails with a 500 due to the missing permissions.

### Logs (if relevant)

security_exception: [security_exception] Reason: action [indices:admin/resolve/index] is unauthorized for user [test_user] with roles [test_dashboard_user,reporting_user], this
action is granted by the index privileges [view_index_metadata,manage,all]
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/privilege/IndexPrivilege.java
/*
 * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
 * or more contributor license agreements. Licensed under the Elastic License
 * 2.0; you may not use this file except in compliance with the Elastic License
 * 2.0.
 */
package org.elasticsearch.xpack.core.security.authz.privilege;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.lucene.util.automaton.Automaton;
import org.elasticsearch.action.admin.cluster.shards.ClusterSearchShardsAction;
import org.elasticsearch.action.admin.indices.alias.get.GetAliasesAction;
import org.elasticsearch.action.admin.indices.close.CloseIndexAction;
import org.elasticsearch.action.admin.indices.create.AutoCreateAction;
import org.elasticsearch.action.admin.indices.create.CreateIndexAction;
import org.elasticsearch.action.admin.indices.delete.DeleteIndexAction;
import org.elasticsearch.action.admin.indices.get.GetIndexAction;
import org.elasticsearch.action.admin.indices.mapping.get.GetFieldMappingsAction;
import org.elasticsearch.action.admin.indices.mapping.get.GetMappingsAction;
import org.elasticsearch.action.admin.indices.mapping.put.AutoPutMappingAction;
import org.elasticsearch.action.admin.indices.resolve.ResolveIndexAction;
import org.elasticsearch.action.admin.indices.rollover.RolloverAction;
import org.elasticsearch.action.admin.indices.settings.get.GetSettingsAction;
import org.elasticsearch.action.admin.indices.validate.query.ValidateQueryAction;
import org.elasticsearch.action.datastreams.CreateDataStreamAction;
import org.elasticsearch.action.datastreams.DeleteDataStreamAction;
import org.elasticsearch.action.datastreams.GetDataStreamAction;
import org.elasticsearch.action.datastreams.PromoteDataStreamAction;
import org.elasticsearch.action.fieldcaps.FieldCapabilitiesAction;
import org.elasticsearch.common.Strings;