### Elasticsearch Version

8.11.0

### Installed Plugins

_No response_

### Java Version

_bundled_

### OS Version

Darwin Kernel Version 22.6.0

### Problem Description

User templates affect Kibana system indices. This is contrary to most system indices https://github.com/elastic/elasticsearch/pull/87933 and causes issues where settings or mappings from the template interfere with the correct working of Kibana.

Based on the description in https://github.com/elastic/elasticsearch/pull/87933 it sounds like the behaviour is intentionally different for Kibana's system indices. Most likely because Kibana used to rely on templates for the user session index. However, it looks like there was maybe a mis-communication because in 8.4.0 Kibana changed this behaviour to no longer rely on templates https://github.com/elastic/kibana/pull/134900 so this should no longer be necessary

### Steps to Reproduce

```
# Based on a real issue a customer faced on ESS
# Create a data stream template matching system indices
curl -X PUT "elastic:changeme@localhost:9200/_index_template/my-ds-template?pretty" -H 'Content-Type: application/json' -d'
{ 
  "index_patterns": [".*"],
  "data_stream": { },
  "priority": 9000,
  "_meta": {
    "description": "Template for my time series data",
    "my-custom-meta-field": "More arbitrary metadata"
  }
}
'

# Create a user able to create Kibana system indices
curl -X PUT "elastic:changeme@localhost:9200/_security/role/grant_kibana_system_indices" -H 'Content-Type: application/json' -d'
{
  "indices": [
    {
      "names": [
        ".kibana*"
      ],
      "privileges": [
        "all"
      ],
      "allow_restricted_indices": true
    }
  ]
}
'             

curl -X POST "elastic:changeme@localhost:9200/_security/user/superduperuser" -H 'Content-Type: application/json' -d'
{
  "password" : "changeme",
  "roles" : [ "superuser", "grant_kibana_system_indices" ]
}
'

# Attempt to create a Kibana system index:
curl -X PUT "superduperuser:changeme@localhost:9200/.kibana_8.11.0_001" -H 'Content-Type: application/json' -d'
{}
'
```

> {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"cannot create index with name [.kibana_8.11.0_001], because it matches with template [my-ds-template] that creates data streams only, use create data stream api instead"}],"type":"illegal_argument_exception","reason":"cannot create index with name [.kibana_8.11.0_001], because it matches with template [my-ds-template] that creates data streams only, use create data stream api instead"},"status":400}


### Logs (if relevant)

_No response_
server/src/main/java/org/elasticsearch/indices/SystemIndexDescriptor.java
* is expanded to "{@code .*}". We don’t support date math or the "-" operator from the
 * {@link org.elasticsearch.cluster.metadata.IndexNameExpressionResolver} class. We intend for developers to use only the "{@code *}",
 * "{@code +}", "{@code ~}" (complement), "{@code (}", "{@code )}", and character class operators, but because of the implementation,
 * other regex operators probably work.
 *
 * <p>Sample index patterns that we want to handle:
 * <ol>
 *     <li>{@code .system-*} - covers all index names beginning with ".system-".
 *     <li>{@code .system-[0-9]+} - covers all index names beginning with ".system-" and containing only one or more numerals after that
 *     <li>{@code .system-~(other-*)} - covers all system indices beginning with ".system-", except for those beginning with
 *     ".system-other-"
 * </ol>
 *
 * <p>The descriptor defines which, if any, Elasticsearch products are expected to read or modify it with calls to the REST API.
 * Requests that do not include the correct product header should, in most cases, generate deprecation warnings. The exception is for
 * "net new" system index descriptors, described below.
 *
 * <p>The descriptor also provides names for the thread pools that Elasticsearch should use to read, search, or modify the descriptor’s
 * indices.
 *
 * <p>A SystemIndexDescriptor may be one of several types (see {@link SystemIndexDescriptor.Type}). The four types come from two different
 * distinctions. The first is between "internal" and "external" system indices. The second is between "managed and unmanaged" system
 * indices. The "internal/external" distinction is simple. Access to internal system indices via standard index APIs is deprecated,
 * and system features that use internal system indices should provide any necessary APIs for operating on their state. An "external"
 * system index, on the other hand, does not deprecate the use of standard index APIs.
 *
 * <p>The distinction between managed and unmanaged is simple in theory but not observed very well in our code. A "managed" system index
 * is one whose settings, mappings, and aliases are defined by the SystemIndexDescriptor and managed by Elasticsearch. Many of the
 * fields in this class, when added, were meant to be used only by managed system indices, and use of them should always be
 * conditional on whether the system index is managed or not. However, we have not consistently enforced this, so our code may have