Mention dot-prefixed patterns in hidden index docs (#81464)

The hidden index docs did not mention that dot-prefixed patterns default
to matching hidden indices. This PR adds a note explaining the behavior
and why it's like that.

docs/reference/api-conventions.asciidoc

@@ -23,11 +23,11 @@ sent with a request. Responses are also UTF-8 encoded.
 [[get-requests]]
 === GET and POST requests
 
-A number of {es} GET APIs--most notably the search API--support a request body. 
-While the GET action makes sense in the context of retrieving information, 
+A number of {es} GET APIs--most notably the search API--support a request body.
+While the GET action makes sense in the context of retrieving information,
 GET requests with a body are not supported by all HTTP libraries.
 All {es} GET APIs that require a body can also be submitted as POST requests.
-Alternatively, you can pass the request body as the 
+Alternatively, you can pass the request body as the
 <<api-request-body-query-string, `source` query string parameter>>
 when using GET.
 
@@ -177,6 +177,11 @@ For most APIs, wildcard expressions do not match hidden data streams and indices
 by default. To match hidden data streams and indices using a wildcard
 expression, you must specify the `expand_wildcards` query parameter.
 
+Alternatively, querying an index pattern starting with a dot, such as
+`.watcher_hist*`, will match hidden indices by default. This is intended to
+mirror Unix file-globbing behavior and provide a smoother transition path to
+hidden indices.
+
 You can create hidden data streams by setting `data_stream.hidden` to `true` in
 the stream's matching <<indices-put-template,index template>>. You can hide
 indices using the <<index-hidden,`index.hidden`>> index setting.
@@ -190,11 +195,11 @@ Global index templates that match all indices are not applied to hidden indices.
 [[system-indices]]
 ==== System indices
 
-{es} modules and plugins can store configuration and state information in internal _system indices_. 
-You should not directly access or modify system indices 
+{es} modules and plugins can store configuration and state information in internal _system indices_.
+You should not directly access or modify system indices
 as they contain data essential to the operation of the system.
 
-IMPORTANT: Direct access to system indices is deprecated and 
+IMPORTANT: Direct access to system indices is deprecated and
 will no longer be allowed in the next major version.
 
 [discrete]
@@ -218,25 +223,25 @@ of the source, such as `application/json`.
 [[api-compatibility]]
 === REST API version compatibility
 
-Major version upgrades often include a number of breaking changes 
-that impact how you interact with {es}. 
-While we recommend that you monitor the deprecation logs and 
+Major version upgrades often include a number of breaking changes
+that impact how you interact with {es}.
+While we recommend that you monitor the deprecation logs and
 update applications before upgrading {es},
-having to coordinate the necessary changes can be an impediment to upgrading. 
+having to coordinate the necessary changes can be an impediment to upgrading.
 
 You can enable an existing application to function without modification after
 an upgrade by including API compatibility headers, which tell {es} you are still
-using the previous version of the REST API. Using these headers allows the 
+using the previous version of the REST API. Using these headers allows the
 structure of requests and responses to remain the same; it does not guarantee
-the same behavior. 
+the same behavior.
 
 
-You set version compatibility on a per-request basis in the `Content-Type` and `Accept` headers. 
-Setting `compatible-with` to the same major version as 
-the version you're running has no impact, 
-but ensures that the request will still work after {es} is upgraded. 
+You set version compatibility on a per-request basis in the `Content-Type` and `Accept` headers.
+Setting `compatible-with` to the same major version as
+the version you're running has no impact,
+but ensures that the request will still work after {es} is upgraded.
 
-To tell {es} 8.0 you are using the 7.x request and response format, 
+To tell {es} 8.0 you are using the 7.x request and response format,
 set `compatible-with=7`:
 
 [source,sh]