mariadb backup: deleting a Backup leaves the dump in the bucket #5197

Describe the bug

Deleting a Cozystack Backup taken with the MariaDB driver removes the Backup object and nothing else. The dump stays in the bucket, the k8s.mariadb.com/Backup CR stays, the operator Job and its completed pod stay.

Environment

Cozystack v1.7.0 with cozy-default on the platform bucket, mariadb-operator 25.10.2. The driver code is the same on main (4087218).

To reproduce

1. Create a MariaDB app and run a BackupJob with cozy-default. The bucket holds <namespace>/<app>/backup.<timestamp>.gzip.sql.
2. kubectl delete backups.backups.cozystack.io <name> -n <namespace>. The object is gone within seconds.
3. List the prefix again, now and 10 minutes later. The dump is still there and kubectl get backups.k8s.mariadb.com -n <namespace> still shows the operator Backup as Complete=True.

Actual behaviour

cleanupOnDelete returns nil for MariaDB (MariaDBStrategyKind case in internal/backupcontroller/backup_controller.go). The only thing that removes a dump is the operator maxRetention, 30 days by default (spec.maxRetention: 720h0m0s on the operator Backup even when the strategy sets none). It deletes files older than the limit from the whole prefix at the end of the next successful backup of that prefix, whether or not a Cozystack Backup still refers to them. So Ready Backup objects with no archive behind them stay: with maxRetention: 1m in a sibling strategy one more backup logged old backups to delete: 3 and the three older Backup objects stayed Ready.

The docs say otherwise. Strategy type comment in api/backups/strategy/v1alpha1/mariadb_types.go says "When empty, retention is unbounded", and docs/operations/backup-classes.md lists CNPG and Velero as the only engine side retention.

Expected behaviour

Dump is removed together with the Backup, like Rabbitmq, Redis, Kafka and MongoDB on the system bucket flow do (the Backup waits for the delete and is released with a warning if it cannot run). The platform bucket has no other retention, Plan has no retention field and never deletes a Backup.

For a fix note that the real object key is <prefix>backup.<RFC3339>.<alg>.sql, not the status.artifact.uri the driver writes (it is built from the operator Backup name and no object has that key), so the driver has to resolve the real key first. Rabbitmq cleanup Job is the pattern.

Related: #3965, #3966, PR #4192.