mariadb: operator-generated metrics-password / repl-password secrets are orphaned after deletion #3056

Describe the bug

After deleting a MariaDB app CR (with metrics and replication enabled), two Secrets created by the mariadb-operator remain in the namespace.

Environment

• Cozystack version: v1.4.0-rc.2
• Provider: on-prem (bare-metal)

To Reproduce

1. Create a tenant, deploy MariaDB/test (replicas: 2, so replication is enabled).
2. Wait until Ready.
3. Delete the MariaDB CR; wait ~120s.
4. kubectl -n <ns> get secret | grep -E 'metrics-password|repl-password' — both secrets remain.

Expected behaviour
No orphaned secrets remain after the app CR is deleted.

Actual behaviour

secret/mariadb-test-metrics-password   Opaque
secret/mariadb-test-repl-password      Opaque

Additional context

• Root cause: These Secrets are generated by the mariadb-operator (k8s.mariadb.com/v1alpha1) as a side effect of the MariaDB CR (metrics.enabled / replication.enabled in packages/apps/mariadb/templates/mariadb.yaml), not by the chart. They are not Helm-owned, and the existing post-delete hook packages/apps/mariadb/templates/hooks/cleanup-pvc.yaml only sweeps PVCs.
• Proposed fix: Extend templates/hooks/cleanup-pvc.yaml:
  • Add secrets to the Role rules: resources: ["persistentvolumeclaims", "secrets"].
  • Add to the cleanup command:

    kubectl delete secret -n {{ .Release.Namespace }} \
      {{ .Release.Name }}-metrics-password {{ .Release.Name }}-repl-password --ignore-not-found || true

Found during a create→delete leak sweep of all 22 apps on Cozystack v1.4.0-rc.2.