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

[HarshwardhanPatil07]

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 bootc-dev/bootc-operator#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.