[Feature]: Use a least-privilege user for Beats ingest instead of the elastic superuser

When Beats ship directly to Elasticsearch, the role authenticates them as the elastic superuser (beats-security.yml greps PASSWORD elastic into beats_writer_password, used in the output as username: "elastic"). That is not least-privilege — Beats ingest only needs write access to its own indices, yet the powerful elastic credentials sit in every Beat config.

Follow Elastic's two-role model:

• writer / publisher user — used by the running config. Minimal: monitor cluster privilege + create_doc / auto_configure on the <beat>-* indices (privileges needed for publishing).
• setup user — used only to run <beat> setup (loads index templates, ILM, ingest pipelines and the Kibana dashboards); admin-level, so grant it only for setup (privileges needed for setup).

Create both via the collection's elasticsearch_role / elasticsearch_user modules. The persisted Beat config uses the writer; the setup step uses the setup user. Constraint: the minimal writer cannot load dashboards, so <beat> setup --dashboards must run as the setup user.

Open at implementation (Ansible-wise): how to hand the setup user's credentials to the setup command only — without persisting them in the config — e.g. -E output.elasticsearch.username=… -E output.elasticsearch.password=… (and setup.kibana.*) passed to the command / via environment. This needs verifying; the exact write/setup split is decided during implementation.

Related: #526 (the authentication axis — this least-privilege user is the credential beats_authentication supplies).

Start by tracing beats-security.yml and the collection's elasticsearch_role and elasticsearch_user modules to see how Beat credentials are created and persisted. Then inspect the Beat setup command entry point and verify that the writer credentials remain in the running config while setup-only credentials are supplied only to setup, including dashboard loading.