When the quay-operator build and publish workflow runs, it pulls components images tagged with `3.6-unstable` to calculate their digests, then updates the operator CSV yaml with the obtained digests before building the catalog image with opm (olm client).

The problem with this approach is that the `3.6-unstable` tag is reused. For example, say the operator catalog was built today, 9am. Then at 10am, a new commit is merged into quay's `redhat-3.6` branch, which will trigger a new build, and push a new version of the `3.6-unstable` tag to quay.io. This means that the operator catalog that was built at 9am now points to a quay digest that no longer exists.

A possible solution is that all components' builds trigger a new quay-operator build using github action's repository_dispatch to trigger events across different repositories.

Another possible solution is to replace the `3.6-unstable` tag with a `3.6-nightly` tag, which is triggered not by push but by schedule. The schedule would have to be syncrhonized so that all components are built before the operator itself, so that it would never end up having outdated digests. The e2e nightly workflow would then be scheduled to run after the operator's own build. This might be the simplest way to go about this.

Acceptance criteria

• builds on components' repositories should not cause the equivalent operator catalog to become invalid without an immedite fix