Capability to retroactively sync a few properties (olm.maxOpenShiftVersion at least) from the catalog to products (CSVs) that are already installed

1. Proposed title of this feature request
Capability to retroactively sync a few properties (olm.maxOpenShiftVersion at least) from the catalog to products (CSVs) that are already installed

2. What is the nature and description of the request?
Being able to retroactively manipulate the FBC catalog via Konflux pipeline, operator authors can now push/amend some CSV/bundle properties down to production.

Unfortunately this is still not enough to close the round trip: the OLM should also sync it back to already successfully deployed products or eventually check them also from the catalog and not simply from existing CSVs.

Example:
v4.14.3 is the latest released version of an operator managed product.
OCP 4.15 is going to be released in the future in a matter of weeks.
Really late in the game we detect that product X v4.14.3 is not going to correctly work on OCP 4.15.
But today we can amend (adding the olm.maxOpenShiftVersion=v4.14 annotation) the FBC catalog that contains product X v4.14.3 and push it to production.
Today the OLM is going to check that annotation form the real CSVs objects (see: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/controller/operators/openshift/helpers.go#L139-L154 ) and new annotations in the catalog are never going to be synced back to the CSVs of successfully deployed products.

So customer A which is already at version v4.14.3 of product X will never get the olm.maxOpenShiftVersion=v4.14 annotation and so he will be allowed to upgrade to OCP 4.15 potentially hitting an issue.

On the other side customer B, that today is at version v4.14.2, will upgrade first to v4.14.3 of product X consuming it from an amended catalog that already contains the recently added annotation and so he will be blocked trying to upgrade to OCP 4.15.

3. Why does the customer need this? (List the business requirements here)

As operator authors we would like to have the capability to retroactively block existing customers from reaching a future OCP minor if we know that they are going to hit some issue there.
Currently we can only get that quickly releasing a .z-stream of the previous minor with the olm.maxOpenShiftVersion annotation there and hoping that customers will consume it before trying to upgrade to the next OCP minor.

4. List any affected packages or components.
All