After postgresql restore, and deleting old backup from S3 container, postgresql/leader remains blocked with `Move restored cluster to another S3 bucket`

## Steps to reproduce

1. Deploy postgresql charm, integrated with `s3-integrator` for backups and `tls-certificates-operator`
2. Create a backup with `juju run postgres/0 create-backup `
3. Remove postgresql application
4. Follow [restore](https://charmhub.io/postgresql/docs/h-restore-backup) instructions
5. Once cluster is restored, postgresql is blocked with "the S3 repository has backups from another cluster".
6. Following instructions [here](https://canonical.com/data/docs/postgresql/iaas/r-statuses), clean the container

## Expected behavior

I expected the charm to detect that the container was now empty, become unblocked, and allow me to re-use the container for new backups.

## Actual behavior

`postgresql/leader` remained in `blocked` status with message `Move restored cluster to another S3 bucket`. I tried restarting the jujud system service and restarting the VM, but the unit remained blocked. The only solution was to create a new bucket.

juju status: https://pastebin.canonical.com/p/X23QQnGJW6/

## Versions

Operating system: Ubuntu 22.04.5 LTS

Juju CLI: 3.5.5-ubuntu-amd64

Juju agent: 3.5.5

Charm revision: postgresql 14/stable 468

## Log output

Juju debug log: https://pastebin.canonical.com/p/jMVZ6JTtZx/

Start with the linked restore instructions and the attached Juju debug log, then trace how the charm determines whether the S3 repository still contains backups from another cluster. Reproduce the restore, cleanup, and restart sequence described in the issue. Done means an emptied S3 container no longer leaves postgresql/leader blocked and can be reused for new backups.

Written by the indexing model from the issue text.