Document the limitation around field aliases and percolator. (#40073)

Currently if a field alias is updated, any percolator queries that contain the
alias will still refer to its old target. This PR documents the issue while we
look into addressing it.

Relates to #37212.

docs/reference/mapping/types/alias.asciidoc

@@ -68,6 +68,10 @@ There are a few restrictions on the target of an alias:
 Additionally, a field alias can only have one target. This means that it is not possible to use a
 field alias to query over multiple target fields in a single clause.
 
+An alias can be changed to refer to a new target through a mappings update. A known limitation is that
+if any stored percolator queries contain the field alias, they will still refer to its original target.
+More information can be found in the <<percolator, percolator documentation>>.
+
 [[unsupported-apis]]
 ==== Unsupported APIs
 

docs/reference/mapping/types/percolator.asciidoc

@@ -743,3 +743,11 @@ The script inside a `script` query can only access doc values fields. The `perco
 into an in-memory index. This in-memory index doesn't support stored fields and because of that the `_source` field and
 other stored fields are not stored. This is the reason why in the `script` query the `_source` and other stored fields
 aren't available.
+
+[float]
+===== Field aliases
+
+Percolator queries that contain <<alias, field aliases>> may not always behave as expected. In particular, if a
+percolator query is registered that contains a field alias, and then that alias is updated in the mappings to refer
+to a different field, the stored query will still refer to the original target field. To pick up the change to
+the field alias, the percolator query must be explicitly reindexed.