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

まず、OSTree と composefs バックエンド上ですでにステージングされているイメージに対して bootc switch --download-only を再現し、次にステージングされた deployment の状態の処理を追跡します。アンロックされた stage がイメージや digest を変更せずにロックされた状態になり、すでにロックされている stage は変更されず、サポートされていない変更には明確なエラーが返されれば、作業は完了です。

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.