[Website]: https://www.elastic.co/docs/reference/elasticsearch/roles

### Before you submit

- [x] This issue is about a documentation page, flow, or piece of content.

### Type of issue

Missing information

### What documentation page or section is affected

https://www.elastic.co/docs/reference/elasticsearch/roles

### What happened?

The section on [Available Built In Roles](https://www.elastic.co/docs/reference/elasticsearch/roles#available-roles) is missing clarification, specifically under `apm_system`.

The `apm_system` built-in role is named as if it were the operational role for APM Server, but per the docs it only covers internal self-monitoring (sending APM Server's own monitoring metrics). It does not grant the privileges needed to actually write APM events. There is a built-in `kibana_system`, `beats_system`, and `logstash_system` for each component, and `kibana_system` is genuinely operational for Kibana — so the `apm_system` naming sets up a reasonable but wrong expectation of parity.

In the Built-in roles reference (8.19), `apm_system` is the only `_system` role missing the standard caveat that beats_system, logstash_system, and kibana_system all carry — "This role should not be assigned to users as the granted permissions may change between releases." Could you confirm whether that omission is intentional? Could we add it as well, similar to `beats_system`.
`
This role should not be assigned to users as the granted permissions may change between releases.`

Thanks!

### Additional info

_No response_

## Action
_added by @georgewallace_
- Look into if `apm_system` is used in some legacy fashion and ensure that the callout is correct