feat(chart): make the relay Deployment strategy configurable

[alxdr3k]

Problem

templates/deployment.yaml hardcodes RollingUpdate with maxSurge: 1 / maxUnavailable: 0, so every rollout briefly runs the old and new relay pods side by side. Each relay pod holds its own writer, audit and search Postgres pools, so a rollout doubles connection demand for its duration.

I hit this self-hosting on a small managed Postgres behind a session-mode pooler with a hard client cap: one pod fits, but during helm upgrade the surge pod pushed the total over the cap and client requests failed with max clients reached in session mode until the old pod drained (~1 min of 500s). A ReadWriteOnce git PVC on a multi-node cluster runs into a similar wall when the surge pod lands on another node.

There is currently no way to opt out without post-render patching the chart output.

Change

• Expose strategy in values.yaml, defaulting to today's behaviour. The default render is byte-identical to main (diffed the full helm template output).
• One subtlety drives the template shape: Helm deep-merges maps, so --set strategy.type=Recreate leaves the default rollingUpdate block in .Values, and the API server rejects rollingUpdate alongside Recreate. The template therefore renders rollingUpdate only when type is RollingUpdate, so switching the type is a one-line change for users.
• values.schema.json: strategy.type is an enum (RollingUpdate | Recreate), so a typo fails at template time.
• README: a short "Rollout strategy" section under Upgrades describing when Recreate is the right trade.

No chart version bump here, since versions are cut through the chart-release/* lane.

Testing

New tests/strategy_test.yaml (4 cases): default strategy, custom rollingUpdate bounds, Recreate with only type set drops rollingUpdate, unknown type is rejected.

Ran the same gates as helm-chart.yml, with the versions it pins (helm v3.16.4, helm-unittest 0.8.2, chart-testing v3.12.0):

helm dependency build deploy/charts/buzz
ct lint --config ct.yaml --all          # both charts linted successfully
helm unittest deploy/charts/buzz        # 11 suites, 53 tests passed
for f in deploy/charts/buzz/ci/*-values.yaml deploy/charts/buzz/tests/fixtures/*-values.yaml; do
  helm template buzz deploy/charts/buzz -f "$f" >/dev/null && echo "ok: $f"
done

Also applied the Recreate render with kubectl apply --dry-run=server against a real cluster (k3s v1.36) to confirm the API server accepts it, and I'm running the equivalent strategy in production now.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is 4e65148e76bd4f8dff757da4014a37fbc95fcc12...0e966e3408b974c61c3abc1c7ad535f1b489a640.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 0e966e3408b974c61c3abc1c7ad535f1b489a640 to authorize a new review.
Any previous review applies only to its recorded range.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.