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-k8s 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 scale-application postgresql-k8s 2
both 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. Also, it works for clusters with more than two units: Screenshot

Operating system: Ubuntu 24.04 LTS

Juju CLI: 3.5.3-genericlinux-amd64

Juju agent: 3.5.3

Charm revision: 347

microk8s: MicroK8s v1.30.1 revision 6843

Juju debug log: debug-log

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-k8s-operator/issues/591 and i think can be done in-batch.
Implement timelines management. Me, @taurus-forever and @marceloneppel tried to discuss it in the issue referenced above.
@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-k8s-operator/issues/614