docs: security-monitoring.md - add second wazuh_agent_tuning incident, bump verify

Re-verified every claim live: 12-agent roster, manager container name,
9 CIS sub-roles + 2 documented deviations, Docker Bench native-binary
story, and the SCA compliance screenshot (139/19/8/87%, confirmed exact
match against automation's live score) all still accurate - no drift.
Added a second real incident found in the same wazuh_agent_tuning file:
a 2026-08-30 fix for the role silently skipping the wazuh host's own
containerized agent.

docs/security-monitoring.md

@@ -1,5 +1,5 @@
-<!-- verified: 2026-09-06
+<!-- verified: 2026-09-19
-     iac@49ff427 : ansible/roles/monitoring/wazuh_agent_tuning, ansible/roles/monitoring/docker_bench, ansible/roles/cis_hardening
+     iac@f770e1c : ansible/roles/monitoring/wazuh_agent_tuning, ansible/roles/monitoring/docker_bench, ansible/roles/cis_hardening
      wazuh-vm@07ed482 : wazuh/docker-compose.yml
      trilium : KpvtX1USDhkY, TstjWVV5Q1TS, OtIgVyQC5lJg, MSVD5o5HiJ69, kA00FQiQWVem, oY5CbyuxZRyS
 -->
@@ -57,6 +57,8 @@ The alternative to an agent on every host is a purely network-level monitoring a
 > # during that night's role redeploys, confirmed via the indexer across
 > # 9 of the fleet's agents.
 > ```
+>
+> The same role found a second gap a month later, in itself this time: it silently skipped tuning the wazuh host's own agent, because that agent runs inside the manager's Docker container rather than natively on the VM — the role's own "is the agent installed" check only ever looked for a native install. That let the wazuh host's own queue sit at the untuned default until a real queue-full alert exposed it, the same class of bug the role was originally written to fix, this time hiding in the one host built differently from the rest. Fixed by giving that host its own branch instead of assuming every agent looks the same.
 
 ## How An Alert Gets Handled