Run Wazuh on Saruman — the heaviest component in ADR-0007

[Gerrrt]

Split out of #101, which named
it directly: "Wazuh in particular is not a small thing to run — it is the
heaviest component in the ADR by a wide margin."

ADR-0007 puts Wazuh on Saruman as part of the defended estate: the thing that
turns the Windows domain from a set of VMs into something that reports what
happened to it.

Blocked behind the domain — an agentless Wazuh has nothing to say.

Why it gets its own issue rather than a line in the umbrella

Wazuh is three services (indexer, server, dashboard), and the indexer is
OpenSearch. Against ADR-0007's stated constraint — "128 GB and 48 threads
against a single mirrored pair of 7.2K disks. The fleet is sized against
spindles, not RAM" — the indexer is the single component in #101 most likely
to be what actually runs out. It is also the one whose default sizing guidance
assumes hardware this host does not have.

Worth deciding before starting

• Retention and shard sizing, from the spindles rather than from the
  defaults.
• Whether it lands in stacks/lab/ or beside it. ADR-0004 says one compose
  stack per host, and the lab guest is one host — which argues for one stack.
  Against: the lab observability stack is four small services and Wazuh is an
  OpenSearch cluster, and make down taking out both is a worse blast radius
  than the ADR was written to consider. Decide it explicitly; do not let it be
  decided by whoever writes the compose file first.
• Its relationship to the lab's Loki. Wazuh has its own store and its own
  dashboard. Two log stores in one lab, each with a UI, is either sensible
  division or duplicated upkeep, and which one depends on whether anything ever
  queries across them.
• Whether the guest can carry it at all, or whether Wazuh wants its own.

Not in scope

Sending anything to 10.0.99.20. Lab telemetry stays in the lab (ADR-0007);
the hypervisor's own agent is the only exception and it predates this (#88).