backupstrategy-controller release Secret is near the 1 MiB cap with no size guard #4174

packages/system/backupstrategy-controller/templates/crds.yaml globs every definitions/*.yaml into one Helm release, and the release Secret is capped at 1 MiB. Three strategy CRDs already carry a full core/v1 PodTemplateSpec schema at around 600 KB each, so there is almost no room left.

Measured while reviewing #3992: without that PR's Redis CRD the payload is about 91% of the cap, with it about 117%. Install then fails for the whole package, not just the new driver.

Helm install failed for release cozy-backup-controller/backupstrategy-controller:
create: failed to create: Secret "sh.helm.release.v1.backupstrategy-controller.v1"
is invalid: data: Too long: may not be more than 1048576 bytes

helm-controller keeps retrying that forever.

The ceiling is already written down, but only for one type. api/backups/strategy/v1alpha1/rabbitmq_types.go says in a field comment that generating the full schema adds ~590 KB and that a fourth such CRD pushes the Secret over the cap, then fixes its own case with +kubebuilder:validation:Schemaless and +kubebuilder:pruning:PreserveUnknownFields. Nothing carries that to the next author. Same package, direct A/B: rabbitmqs is 9,268 bytes with the markers, jobs is 601,779 without.

Nothing checks the rendered size. So the next strategy CRD written without the markers passes review and fails at install after merge, and the error names a Secret instead of the type that caused it.

Two ways out, and they are not exclusive. Require the schemaless markers for any strategy CRD carrying a PodTemplateSpec and enforce it with a test over api/backups/strategy/v1alpha1/. Or move the CRDs out of the Helm release onto their own apply path, which drops the shared budget entirely. A size check in the package build would turn this into a review-time failure either way.