Rollout gate: exercise enabled deletion-drain CronJob before enabling chart

[TheSentinel454]

Rollout gate

Do not enable operatorJobs.deletionDrain.enabled in a deployed chart until an enabled-chart live execution receipt is captured on a suitable disposable Kubernetes cluster. Defaults remain false at #7827 head 464a4e60e042949b49b5058e97895e7a14ef25f3 (deploy/charts/buzz/values.yaml:397–403). This issue tracks a proposed named runtime exception for merging the disabled-by-default chart, not acceptance of that exception or runtime PASS.

Concrete blocker

At that exact head, bounded Blox setup found no private cluster. One permitted non-Quay image pull succeeded (rancher/k3s:v1.31.5-k3s1, image sha256:53cf744fe2fabf140cee240d2db70d13a4f2d98f1a13c98f58f457f423096917), but the one private launch exited 1 before node readiness:

Failed to start ContainerManager: cannot enter cgroupv2 "/sys/fs/cgroup/kubepods" with domain controllers -- it is in an invalid state

No chart/namespace/CronJob/Job was created. Job attempts 0. No shared-cluster mutations, launch retries or cgroup workarounds; owned cluster resources were removed. The exact #7827 migration target is 0051, not #7830's 0052.

Required evidence before enabling

• On an isolated capable cluster, apply the enabled chart from the intended deployment SHA, with an exact-head image containing buzz-admin; disclose fixture-only packaging differences.
• Owned healthy Postgres/Redis, zero deletion requests/leases, static noncredential S3 placeholders and refused pod-loopback S3 endpoint; no tenant destruction or real media access.
• Create one Job from the chart CronJob and retain pod/image/command/environment wiring, logs and exit 0; verify unchanged zero-work SQL/Redis before/after.
• Verify live concurrencyPolicy: Forbid and configured history limits (defaults 1 successful/3 failed). A manual Job alone does not prove scheduled execution, overlap prevention or pruning: separately exercise controller behavior before claiming those behaviors verified, or explicitly document its remaining scope.
• Preserve manifest, exact head/tree, timestamps and teardown proof. Resolve this rollout gate only after review of the actual receipt.

Existing evidence

Chart lint/render/schema and Kubernetes API validation do not substitute for pod execution. #7830's successful no-work CLI receipt at dc0a125 does not exercise this CronJob.

Blox buzz-community-self-delete:

• /home/bloxer/PR7827_ENABLED_CRONJOB_464A4E60_REPORT.md, sha256 81be017bf41efe7925fbcce2bfa61870a8180219fec924d823b736af939fa506
• /home/bloxer/PR7827_ENABLED_CRONJOB_464A4E60_ADDENDUM.md, sha256 e40f9661c56f4a5bc20e9c8db01788dc557c2fa535cf892f703265bf5e8d3e2a
• /home/bloxer/pr7827-enabled-cronjob-464a4e60-angle2-evidence/SHA256SUMS, sha256 7af3d155bdd926f6a6edc31a6b0d114650cfb54a7bd3d747e8ece9a04113b3a6 (9/9 independently checked by Gimli)

Related: #7827

[TheSentinel454]

Gandalf accepted the named Blox private-cluster cgroupv2 startup exception for merging the disabled-by-default chart. This issue remains a mandatory rollout gate before enabling it, not a live execution PASS. Suggested next diagnostic (not validated here): investigate kind/k3d entrypoint handling of nested cgroupv2, including moving processes out of the root cgroup before enabling domain controllers. This may address the observed kubelet ContainerManager error; do not treat it as a proven fix or modify shared workstation cgroups without authorization. A suitable isolated cluster/VM is an alternative. No further cluster attempt is currently authorized.