opensearch: carry vm.max_map_count in the node contract so the operator DaemonSet can go #4144

Problem / motivation
OpenSearch refuses to start unless vm.max_map_count is at least 262144, and Kubernetes cannot set that sysctl from a Pod: it is not in kubelet's namespaced set, so the only paths are node configuration or a privileged container. Today nothing in the node contract carries it: the Talos profiles under packages/core/talos set no sysctls, the talm charts (charts/cozystack/templates/controlplane.yaml, worker.yaml) carry no sysctls block, and ansible-cozystack does not set it either, so nodes sit at the kernel default of 65530. #4131 covers the immediate symptom (the operator's privileged init container is refused in tenant namespaces) and gets a DaemonSet in the operator's namespace as the runtime fix; this issue is the durable half.

Proposed solution
Carry vm.max_map_count: 262144 in the node contract everywhere a Cozystack node is produced: machine.sysctls in the talm chart templates, the equivalent in the ansible-cozystack prepare playbooks, the Talos profiles or e2e cluster preparation used by CI, and the documentation for hand-prepared nodes. Once every supported install path sets it, the DaemonSet from #4131 can be removed and the operator flag stays off.

Scope check

• This affects a single component / package (it spans talm, ansible-cozystack, the e2e cluster and docs)
• I can describe the expected behavior concretely

Alternatives considered
Keeping the DaemonSet forever: it works, but it is a privileged Pod on every node for one optional application. node.store.allow_mmap: false in the chart: drops the requirement but moves every OpenSearch instance onto niofs, which upstream treats as the fallback store, not the default.

Additional context
Found while running the first e2e suite for opensearch (#2682, run 34071594228).