After scaling and changing s3-integrator config, "Move restored cluster to another S3 bucket" blocked status won't disappear for non-primary units

Steps to reproduce

use 1 unit of postgresql with configured s3-integrator
restore backup
single unit (restore can be done only on single unit) became in "Move restored cluster to another S3 bucket" blocked status as it should be
juju add-unit postgresql -n 2
all the units became in "Move restored cluster to another S3 bucket" blocked status
configure s3-integrator to use different path (for example, juju config s3-integrator path=backup-test2)
observe, that only primary unit did loose "Move restored cluster to another S3 bucket" blocked status and became active / idle

All of the units should loose "Move restored cluster to another S3 bucket" blocked status after S3 configuration is changed.

See step 7.

Operating system: Ubuntu 24.04 LTS

Juju CLI: 3.5.3-genericlinux-amd64

Juju agent: 3.5.3

Charm revision: 454

LXD: 6.1

Juju debug log: debug-log

I will just paste below what i said in the K8s issue.

Basically, there is three paths to fix it:

Improve S3 relation code. So it will be related to the similar bug discovered previously - https://github.com/canonical/postgresql-operator/issues/572 and i think can be done in-batch.
Implement timelines management. Me, @taurus-forever and @marceloneppel tried to discuss it in https://github.com/canonical/postgresql-k8s-operator/issues/591.
@taurus-forever proposed to block user from scaling application in potentially breaking scenarios.

Timelines management will:

allow us not to use Move restored cluster to another S3 bucket logic
allow user to see all the lifespan of cluster (not just separated to different S3 buckets after each restore) and effectively navigate through different timelines of it
imply WAL archiving refactor, that will fix issues like https://github.com/canonical/postgresql-operator/issues/463