feat(vaultwarden): add topologySpreadConstraints support

[somaz94]

What this does

Adds an opt-in topologySpreadConstraints field so pods can be spread across zones/nodes for higher availability. This complements the existing nodeSelector, affinity, tolerations, and priorityClassName scheduling knobs already exposed on the pod spec.

Why

Multi-node clusters running more than one replica (replicas > 1, or a StatefulSet) currently have no built-in way to enforce even pod distribution across topology domains. topologySpreadConstraints is the standard Kubernetes primitive for this and rounds out the scheduling surface of the chart.

Changes

• templates/_podSpec.tpl — render topologySpreadConstraints from values (shared by both the Deployment and StatefulSet paths via vaultwarden.podSpec)
• values.yaml — new topologySpreadConstraints: [] parameter with @param doc annotation
• README.md — regenerated via the bitnami readme-generator-for-helm tool (generate-readme.sh)
• Chart.yaml — version bump 0.43.1 → 0.44.0 (SemVer minor, per CONTRIBUTING)

Backward compatibility

The field defaults to [], so the {{- with .Values.topologySpreadConstraints }} block is skipped when unset. Rendered output for existing users is byte-identical (verified with helm template diff against main, version bump aside).

Usage

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: vaultwarden

Testing

• helm lint — pass
• ct lint — pass
• helm template with the field set renders topologySpreadConstraints correctly on both Deployment and StatefulSet
• helm template with the field unset is byte-identical to main