Keep Hubble relay replicas on separate production nodes #5576

🤖 Generated by the Agentic Engineer

Expected Behavior

The production Hubble relay remains available after losing one node. Its two replicas use separate eligible nodes, and a placement change preserves the Cilium datapath, admission controls and existing disruption budget.

Actual Behavior

The declared relay placement uses ScheduleAnyway, which expresses a preference and permits both replicas to share a node. The soft spread introduced by #2125 therefore does not guarantee the intended availability outcome. This is visible in the public configuration; private runtime evidence is retained separately.

Steps to Replicate

1. Render the pinned Cilium chart with the production HelmRelease values.
2. Inspect the Hubble relay Deployment's topology constraint and selector.
3. Observe that its scheduling rule permits a placement that leaves both replicas dependent on one node.

Acceptance Criteria

• Render a placement rule that prevents the two production relay replicas sharing one eligible node, with selectors matching the actual chart output.
• Preserve replica counts, resource requests, disruption protection, security contexts and datapath configuration; compare the complete chart output to detect unrelated changes.
• Validate local and production configurations and keep single-node development behavior explicit.
• Deliver through current-head CI, substantive review and the protected merge queue.
• Verify two ready deployed replicas on separate nodes and observe the corresponding Coroot availability risk clear without dismissal or a changed observation window.

Related to #2125. Part of #2043.

Scheduling semantics: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/