Channel is not updated when both spec.desired.image and spec.desired.channel are set in UpgradeConfig

[pazpuwi]

Summary

When an UpgradeConfig has spec.desired.image populated alongside spec.desired.channel
and spec.desired.version, the operator performs the version upgrade but never updates the
cluster's channel to match spec.desired.channel. This means that after a cross-minor
upgrade (e.g. stable-4.20 -> stable-4.21), the cluster's channel stays on the old value and
has to be changed manually afterwards via oc adm upgrade channel.

Steps to reproduce

1. Cluster is on channel stable-4.20, running version 4.20.27.
2. Create/update an UpgradeConfig with all three desired fields populated, e.g.:

   spec:
     desired:
       channel: stable-4.21
       image: quay.io/openshift-release-dev/ocp-release@sha256:<digest>
       version: 4.21.27

3. The upgrade proceeds and the cluster is successfully updated to version 4.21.27.
4. The cluster's channel remains stable-4.20 instead of being updated to stable-4.21,
   even though channel: stable-4.21 was explicitly set in the UpgradeConfig.

Expected behavior

When spec.desired.channel is set and differs from the cluster's current channel, the
operator should update the cluster's channel to match, regardless of whether the upgrade
is being driven via spec.desired.image or via spec.desired.channel + spec.desired.version.
Today this only appears to happen for the latter case, not when image is also set.

Impact

Admins/automation that populate image (e.g. to pin an exact release) together with
channel for cross-minor upgrades end up with a cluster left on the wrong channel after
the upgrade completes, requiring a manual follow-up step to correct it. This is easy to
miss and can go unnoticed until the next upgrade cycle.