Fix bugs found in role tasks and templates

[Oddly]

A deep audit of the roles and templates turned up several correctness issues ranging from crash risks to silent misbehaviour.

Rolling upgrade crash risk (elasticsearch/tasks/main.yml:218) — the rolling upgrade trigger checks ansible_facts.packages['elasticsearch'][0].version is defined without first checking that the elasticsearch key exists in ansible_facts.packages. If ES isn't installed yet, this throws a Jinja2 KeyError before the is defined test can suppress it. The pre-upgrade block at line 168 does it correctly with ansible_facts.packages['elasticsearch'] is defined as the first guard. The rolling upgrade trigger should match that pattern.

Rocky Linux 10 string comparison (repos/redhat.yml) — uses ansible_facts.distribution_major_version >= "9" which is a string comparison. "10" >= "9" evaluates to false lexicographically because "1" < "9". Should use | int >= 9.

Logstash handler missing check_mode guard — the ES, Kibana, and Beats handlers all include not ansible_check_mode in their when conditions. Logstash's handler does not, so it would attempt a real service restart during --check runs.

Duplicate logstash_ident stamping — the logstash_ident mutate block is emitted in both 50-filter.conf.j2 (using inventory_hostname) and 90-output.conf.j2 (using ansible_facts.hostname). When both files are deployed — which is the normal case when filters and output are both configured — every event gets the ident field stamped twice with potentially inconsistent values. One of the two blocks should be removed.

Beats hardcoded ssl.verification_mode: none — all three beat templates (auditbeat.yml.j2, filebeat.yml.j2, metricbeat.yml.j2) hardcode ssl.verification_mode: none for the ES output, disabling certificate validation even when a CA is deployed. No variable controls this. The Logstash output in the same templates uses full, making the inconsistency more surprising.

ES audit appender always emitted — elasticsearch/templates/log4j2.properties.j2 writes the audit log appender unconditionally, including when elasticsearch_security: false. There is no elasticsearch_logging_audit guard, so the appender exists even when audit logging is irrelevant.