Barman Cloud compatibility: enforce retention against the legacy Barman Cloud archive

## Problem

Once a cluster has migrated to Klio and the barman-cloud plugin is decommissioned, nothing enforces retention on the legacy Barman Cloud archive any more: its base backups and WAL will never be expired or deleted unless Klio takes over that responsibility. This is the one write/delete path against Barman Cloud objects deferred from the WAL fallback and base-backup fallback tickets.

## Requirements

- This is the only write or delete operation Klio ever performs against Barman Cloud objects; the WAL and backup fallback paths remain strictly read-only.
- Deleting a Barman Cloud base backup must remove all of its constituent objects (all tablespace tars, `data.tar`, `backup.info`) completely: no orphaned objects left behind on partial failure.
- A Barman Cloud backup or WAL segment still required by a valid recovery target must never be deleted, regardless of the configured retention window.
- The local Barman Cloud catalog cache (sibling caching ticket) must reflect deletions immediately: it must not continue to offer deleted backups or WAL for restore.
- Feature is off by default and must be explicitly enabled; fully inert otherwise, with no object-store calls beyond normal fallback reads.

## Verification

- [ ] Applying retention against a Barman Cloud archive deletes only backups/WAL segments genuinely beyond the configured retention window, confirmed by test.
- [ ] Deletion of a base backup is all-or-nothing: a partial failure (e.g. an object-store call fails mid-deletion) leaves no orphaned tablespace tars or dangling `backup.info`.
- [ ] A Barman Cloud backup or WAL segment still required by a valid recovery target is never deleted, confirmed by test.
- [ ] The local catalog cache reflects a deletion immediately after it completes: no stale entries served for restore afterwards.
- [ ] Feature is off by default; enabling/disabling it is the only thing that changes behaviour.
- [ ] Covered by an integration/e2e test against a real Barman Cloud archive, including a forced partial-failure scenario.

## Open questions

- Does the legacy Barman Cloud archive get its own independent retention policy configuration, or does it inherit the cluster's existing tier2 retention policy?
- What triggers a retention pass against the Barman Cloud archive: the same schedule as Klio's native retention, a one-off manual trigger, or something else?
- How does this interact with the catalog cache's invalidation model, given the caching ticket left that open?

## Out of scope

- Barman Cloud's own retention enforcement while it's still the active, pre-migration plugin.
- The WAL fallback and base-backup fallback read paths (sibling tickets, this ticket concerns deletion only).