Stage 5: installer chart + release infra, kind e2e pass through the chart

Chart (charts/terdut-operator) generated via kubebuilder's own helm/v2-alpha
plugin from config/'s kustomize output -- CRDs + manager Deployment/RBAC
come from the same markers every other stage already generates, one source
of truth. Hand-added on top: the optional terdutServer values block
(DESIGN.md §10's "helm install and get a server" path, off by default) and
the release-skill plumbing -- .release.conf, release-vars/helm-lint/push/
helm-package/helm-push/release Makefile targets, .gitea/workflows/release.yaml
(test -> image/chart -> scan-image) -- mirroring terdut-server's own shape
(registry/namespace convention, multi-arch buildx push, trivy/govulncheck/
gitleaks scans). ci.yaml gains security and chart jobs to match.

Two real issues caught while wiring this, fixed before either shipped:
- Dockerfile's builder stage didn't pin --platform=$BUILDPLATFORM, which
  would have made a multi-arch release build fail outright on this org's
  runners (no binfmt registration) -- same fix terdut-server's own
  Dockerfile already needed for the same reason.
- govulncheck found one real, reachable finding: google.golang.org/grpc
  v1.82.1 (transitive via controller-runtime's otel exporter), fixed by
  bumping to v1.83.1.

Full golden-path kind e2e pass, this time through `helm install` rather than
raw kustomize: TerdutServer (real terdut-server v0.33.0 image) -> TerdutTeam
-> one of each child kind, each confirmed Ready and then independently
confirmed against terdut-server's own API from inside the cluster (not just
the operator's own status). Deleted every CR in reverse order and confirmed
server-side cleanup the same independent way for all three child kinds, the
team, and the server. No new bugs found -- Stage 1's own kind pass already
caught what a real cluster catches that envtest can't.

Also dropped the kubebuilder helm plugin's default .github/workflows/
scaffold, same as Stage 0 already did for the main scaffold: this org runs
on Gitea, not GitHub.

Not done here, deliberately: an actual tagged release. release-preflight
found no terdut-operator/ entry under Ryuvia/charts yet to bump -- that
one-time wrapper bootstrap is a decision about deploying this operator for
real, not a side effect of finishing this stage.

make fmt lint test helm-lint build all clean.

ROADMAP.md

@@ -181,6 +181,53 @@ New commits build forward over the old ones; no git history rewrite.
   → one of each child kind → verify via terdut-server's own API that each
   object exists with the right shape → delete the CR → verify the
   server-side object is gone.
+- Chart built via kubebuilder's own `helm/v2-alpha` plugin from `config/`'s
+  kustomize output (`charts/terdut-operator`), not hand-rolled -- CRDs +
+  manager Deployment/RBAC come from the same markers/manifests every other
+  stage already generates, so there's exactly one source of truth for
+  them. Hand-added on top: the optional `terdutServer` values block (§10's
+  "helm install and get a server" path), `.release.conf`, and the
+  `release-vars`/`helm-lint`/`push`/`helm-package`/`helm-push`/`release`
+  Makefile targets `.gitea/workflows/release.yaml` calls, mirroring
+  terdut-server's own shape end to end (same registry/namespace
+  convention, same multi-arch buildx push, same trivy/govulncheck/gitleaks
+  scans). Also fixed while wiring this: the Dockerfile's builder stage
+  didn't pin `--platform=$BUILDPLATFORM`, which would have made a
+  multi-arch release build fail outright on this org's runners (no binfmt
+  registration) -- caught before it ever shipped, not discovered mid-release;
+  and govulncheck surfaced one real, reachable finding (`google.golang.org/grpc`
+  v1.82.1, transitive via controller-runtime's otel exporter), fixed by
+  bumping to v1.83.1.
+- **Done, 2026-10-01**: the full golden-path pass above, run for real
+  against a `kind` cluster, installed via `helm install` (not raw
+  kustomize/kubectl apply -- the first time the chart itself, not just
+  `config/`, was exercised): `TerdutServer` (real terdut-server `v0.33.0`
+  image, bring-your-own DSN against a throwaway in-cluster Postgres) →
+  `TerdutTeam` → one `TerdutEscalationRule` + `TerdutDeadmanSwitch` +
+  `TerdutAlertSource`, each confirmed `Ready` and then confirmed a second
+  way, independent of the operator's own status: a `curl` pod inside the
+  cluster, authenticated with the generated team credential, hit
+  terdut-server's real API directly (`GET /api/teams/{id}/escalation`,
+  `.../deadman/switches`, `.../integrations`) and got back exactly the
+  policy/switch/integration each spec declared. Deleting every CR in
+  reverse order was verified the same way: the escalation policy came back
+  empty (its only available "undo"), the switch and the integration were
+  both gone from their list endpoints, the team no longer resolved by
+  name, and the Deployment/Service/every generated Secret were gone from
+  the cluster. No new bugs found this pass -- Stage 1's own kind e2e pass
+  already caught the two issues (`events.k8s.io` RBAC, the podman
+  `.dockerignore` fix) a real cluster catches and `envtest` can't, and
+  nothing since has touched that surface.
+- Not done in this pass, deliberately: an actual tagged release. `make
+  release-vars`/`helm-lint`/`push`/`helm-package`/`helm-push` all work
+  locally and `.gitea/workflows/release.yaml` is wired, but
+  `release-preflight` found there is no `terdut-operator/` entry under
+  `Ryuvia/charts` yet to bump -- every other onboarded repo had that
+  one-time wrapper-chart bootstrap done for it before its own first
+  release, and this one doesn't, since deploying this operator for real is
+  a decision for whoever runs the cluster, not a side effect of finishing
+  this stage. Cutting the first real release (and creating that wrapper
+  entry) is therefore the next action, not yet taken.
 
 ## Deferred (§13, unchanged by this roadmap)