Support locking an existing staged deployment with --download-only

Empieza reproduciendo bootc switch --download-only con una imagen ya preparada en los backends OSTree y composefs, y luego sigue el tratamiento del estado del deployment preparado. El trabajo estará terminado cuando una stage desbloqueada pase a estar bloqueada sin cambiar su imagen ni su digest, una stage que ya esté bloqueada permanezca sin cambios y los cambios no compatibles devuelvan un error claro.

Problem

Running bootc switch --download-only for the same image that is already
staged does not convert the staged deployment from unlocked to download-only.
Instead, bootc exits successfully without changing the staged deployment:

Image specification is unchanged.

The staged deployment continues to report:

{
  "downloadOnly": false
}

This means management software cannot safely enable a policy requiring an
explicit apply operation after the image has already been staged.

The result was reproduced on both:

• OSTree backend using XFS
• composefs backend using ext4, GRUB and BLS

Both returned Image specification is unchanged. with exit status 0, and both
left status.staged.downloadOnly set to false.

The OSTree-specific ostree admin lock-finalization command may provide a
low-level workaround, but it is not a backend-independent bootc interface.

Background Why this matters https://github.com/bootc-dev/bootc-operator/pull/151

While implementing RequireSoftReboot support in bootc-operator, we need to
guarantee that a staged deployment cannot be applied by an ordinary reboot
before the operator explicitly applies it.

For RequireSoftReboot, the operator must ensure that an ordinary reboot
cannot accidentally apply the staged image.

If RequireSoftReboot is enabled after an update was staged normally,
bootc-operator currently cannot safely lock that existing stage. It must reject
the policy transition and report SoftRebootStageUnlocked.

Expected Behavior:

If changing the state is unsupported, the command should return a clear error
instead of successfully reporting that the image specification is unchanged.

The operation should ideally be idempotent:

• An unlocked staged deployment becomes locked.
• An already locked deployment remains locked.
• The selected image and digest do not change.

A backend-independent bootc operation would let the operator safely adopt the
existing stage instead.