On the OSTree side, we've for a while now supported finalization locking:

https://github.com/ostreedev/ostree/pull/1841

This allows update drivers (like the MCO) to pull and deploy an update ahead of time to minimize the amount of the work that needs to happen while drained but still retain the semantic that the node will not reboot into the update until the lock is lifted.

This is used by zincati https://github.com/coreos/zincati/blob/10ff2c9658978e7dc847c3a9a6a13cc1db685972/src/rpm_ostree/cli_deploy.rs#L114

This means that the MCD could do ahead of time something like:

rpm-ostree rebase --lock-finaliation ...

(presumably when the customer initiates a cluster upgrade and the target OS, whether OCL-built or not is known), and then when "rolling out", do

rpm-ostree finalize-deployment

Which "lifts" the lock and immediately reboots the system.

bootc does not yet support finalization locking, but should in the future. (And in the longer future, this might be implemented differently if OSTree is no longer involved, but the API should remain the same.)
https://github.com/bootc-dev/bootc/issues/1320