[bootc 1.15.2 - almalinux-bootc:10.2] Consecutive soft-reboot transitions do not activate the expected target deployment

## Summary

Consecutive `bootc` operations using `--apply --soft-reboot=required` on a ostree-backed system trigger systemd soft-reboots, but the expected target deployment is not activated on the second transition.

This reproduces with both `bootc rollback` and `bootc upgrade`.

## Environment

- Repository: `bootc-dev/bootc`
- Backend: ostree with composefs enabled
- Commands tested with `--apply --soft-reboot=required`
- `bootc status --verbose` showed both booted and rollback deployments as `Soft-reboot: yes`
- `bootc --version` -> `1.15.2 (almalinux-bootc:10.2)`

## Reproduction

Starting state:

- Booted image: `my-repo/my-project/my-image:A`
- Rollback image: `my-repo/my-project/my-image:B`
- Both entries reported `Soft-reboot: yes`

Then run:

1. `bootc rollback --apply --soft-reboot=required`
2. Verify the system is now booted into `my-image:B` and rollback points to `my-image:A`
3. Run `bootc rollback --apply --soft-reboot=required` again

A similar issue is observed with consecutive `bootc upgrade --apply --soft-reboot=required` operations.

## Expected behavior

If both the current and target deployments are reported as `Soft-reboot: yes`, a second consecutive soft-reboot-capable transition should activate the requested target deployment.

For rollback specifically, the second rollback should return the system to the previous deployment.

## Actual behavior

The second soft-reboot is triggered by systemd, but the expected target deployment seems not to be activated.

After the second rollback, `bootc status --verbose` still shows the same booted/rollback pair instead of flipping back.

However, the userspace filesystem seems to be the expected one. So, what is returned by `bootc status` doesn't match with what is actually done.

Journal output confirms that a second soft-reboot occurred:

```text
Aug 18 14:24:08 ar-node-153 systemd[1]: Soft-rebooting.
Aug 18 14:25:01 ar-node-153 systemd[1]: Soft-reboot finished in 57.036s, counter is now at 1.
...
Aug 18 14:29:18 ar-node-153 systemd[1]: Soft-rebooting.
Aug 18 14:30:25 ar-node-153 systemd[1]: Soft-reboot finished in 1min 11.431s, counter is now at 2.
```

`ostree admin status` after preparing the second transition shows a pending soft-reboot deployment:

```text
default ddf9cef2ccbd4637f3f5b4fc9d366aa3273ca3c3b1d5ba9bbff0910d7f19d650.1 (pending) (soft-reboot)
origin:
* default cbdc4faca29a53293e0f717abb4d387b89470cd5c618ff68a702de2ba99d233a.0
origin:
```

So the soft-reboot appears to be prepared, but the resulting active deployment after the reboot does not match expectations.

## Additional notes

This does not appear to be a generic systemd limitation, because systemd reports completing two consecutive soft-reboots successfully. The problem seems specific to how bootc prepares or consumes the pending deployment for a second consecutive soft-reboot-capable transition.

Relevant implementation areas in the repository include:

- `crates/lib/src/bootc_composefs/soft_reboot.rs`
- `crates/lib/src/bootc_composefs/update.rs`
- `crates/lib/src/bootc_composefs/rollback.rs`

## Possible direction

Investigate consecutive soft-reboot flows for both staged upgrades and rollback/revert flows, especially cases where a new `pending (soft-reboot)` deployment is prepared after a previous soft-reboot has already occurred.

Start by tracing consecutive soft-reboot handling in crates/lib/src/bootc_composefs/soft_reboot.rs, then follow staged upgrade and rollback flows in update.rs and rollback.rs. Reproduce with consecutive `bootc rollback --apply --soft-reboot=required` and upgrade operations, inspecting `bootc status --verbose` and `ostree admin status`. Done means the requested deployment is activated after the second transition and status matches the userspace filesystem.

Written by the indexing model from the issue text.