### 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
* inconsistent expectations about what fields will be defined for an unmanaged index. (In the future, we should refactor so that it
 * is clear which fields are ignored by unmanaged system indices.)
 *
 * <p>A managed system index defines a "primary index" which is intended to be the main write index for the descriptor. The current
 * behavior when creating a non-primary index is a little strange. A request to create a non-primary index with the Create Index
 * API will fail. (See <a href="https://github.com/elastic/elasticsearch/pull/86707">PR #86707</a>) However, auto-creating the index by
 * writing a document to it will succeed. (See <a href="https://github.com/elastic/elasticsearch/pull/77045">PR #77045</a>)
 *
 * <p>The mappings for managed system indices are automatically upgraded when all nodes in the cluster are compatible with the
 * descriptor's mappings. See {@link SystemIndexMappingUpdateService} for details.
 *
 * <p>We hope to remove the currently deprecated forms of access to system indices in a future release. A newly added system index with
 * no backwards-compatibility requirements may opt into our desired behavior by setting isNetNew to true. A "net new system index"
 * strictly enforces its allowed product origins, and cannot be accessed by any REST API request that lacks a correct product header.
 * A system index that is fully internal to Elasticsearch will not allow any product origins; such an index is fully "locked down,"
 * and in general can only be changed by restoring feature states from snapshots.
 */
public class SystemIndexDescriptor implements IndexPatternMatcher, Comparable<SystemIndexDescriptor> {
    public static final Settings DEFAULT_SETTINGS = Settings.builder().put(IndexMetadata.SETTING_INDEX_HIDDEN, true).build();
    /**
     * A pattern, either with a wildcard or simple regex. Indices that match one of these patterns are considered system indices.
     * Note that this pattern must not overlap with any other {@link SystemIndexDescriptor}s and must allow an alphanumeric suffix
     * (see {@link SystemIndices#UPGRADED_INDEX_SUFFIX} for the specific suffix that's checked) to ensure that there's a name within the
     * pattern we can use to create a new index when upgrading.
     * */
    private final String indexPattern;
    /**
     * For internally-managed indices, specifies the name of the concrete index to create and update. This is required
     * since the {@link #indexPattern} can match many indices.
     */