Support topologySpreadConstraints for VectorAggregator and ClusterVectorAggregator

[stigglor]

Summary

Add an optional spec.topologySpreadConstraints to VectorAggregator and
ClusterVectorAggregator, passed through to the aggregator pod template.

Motivation

Aggregator replicas need to spread across availability zones, for failure isolation
and to keep cross-AZ traffic down. spec.affinity is already passed through, but pod
anti-affinity cannot express this:

• preferredDuringSchedulingIgnoredDuringExecution is a soft score. Under a
  provisioner like Karpenter, which provisions nodes to fit pending pods, it does not
  compel a second node, so replicas end up packed onto one node in one zone.
• requiredDuringSchedulingIgnoredDuringExecution has no count parameter, so it caps
  at one pod per zone. Any replica count above the zone count leaves the extra pods
  Pending, which rules it out for HPA-driven scaling (feat: Add HPA support for VectorAggregator and ClusterVectorAggregator CRDs #225).

topologySpreadConstraints with maxSkew and whenUnsatisfiable: ScheduleAnyway is
the only way to express "spread evenly, but never block scheduling".

Proposed behavior

• New optional field topologySpreadConstraints []corev1.TopologySpreadConstraint on
  the aggregator common spec.
• Passed to the aggregator pod spec alongside the existing affinity, tolerations
  and schedulerName.
• Unset means no constraints, so no behaviour change for existing users.
• Covers both the Deployment and StatefulSet paths, since both use
  aggregatorPodTemplateSpec().

Scope / implementation notes

• api/v1alpha1/vector_common_types.go: add the field.
• internal/vector/aggregator/deployment.go: set it in aggregatorPodTemplateSpec().
• internal/vector/aggregator/event_collector.go: same, for consistency.
• Regenerate deepcopy and CRDs. No RBAC change.

Happy to open a PR if the approach looks right.