### 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
import org.elasticsearch.xpack.core.ccr.action.ForgetFollowerAction;
import org.elasticsearch.xpack.core.ccr.action.PutFollowAction;
import org.elasticsearch.xpack.core.ccr.action.UnfollowAction;
import org.elasticsearch.xpack.core.ilm.action.ExplainLifecycleAction;
import org.elasticsearch.xpack.core.rollup.action.GetRollupIndexCapsAction;
import org.elasticsearch.xpack.core.security.support.Automatons;
import org.elasticsearch.xpack.core.transform.action.GetCheckpointAction;
import java.util.Arrays;
import java.util.Collection;
import java.util.Collections;
import java.util.HashSet;
import java.util.Locale;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
import java.util.function.Predicate;
import static java.util.Map.entry;
import static org.elasticsearch.xpack.core.security.support.Automatons.patterns;
import static org.elasticsearch.xpack.core.security.support.Automatons.unionAndMinimize;
/**
 * The name of an index related action always being with `indices:` followed by a sequence of slash-separated terms
 * that generally describes the hierarchy (from broader to more specific) of the action. For example, the
 * first level comprises `admin`, `monitor`, `data` which generally categorize an action into either an admin
 * related function, or a monitoring related function or a user-data related function. Subsequent levels further
 * narrow down the category until the meaning is specific enough.
 *
 * Note that these terms are meant to categorize what the action does, *not* how it should be invoked. This means
 * whether an action is accessible via REST API should not contribute to its naming.
 *
 * Also note that the `internal:transport/proxy/` prefix is automatically added and stripped for actions that go