Add --dry-run flag to migrate for change-management environments

[rocketman-code]

Motivation

For environments where change management requires a documented plan reviewed and approved before execution (regulated/research/enterprise), a dry-run that shows the exact sequence of operations `migrate` would perform is valuable. Today `check` partially serves this purpose by validating boot chain readiness, but it does not enumerate the specific steps that will run.

Scope

`atomic-rollback migrate --dry-run` (also `atomic-rollback setup --dry-run`) prints what the command would do, in order, with no filesystem modifications. Output includes:

• Each numbered step (the existing `step1_...` through `step10_...` for migrate)
• The specific action(s) the step would take, with concrete paths/devices derived from the live system (fstab, root device, kernel version, etc.)
• The BOOTS gate that would execute after each step
• Final summary: estimated total operations, files touched, RENAME_EXCHANGE points

Properties

• No mounts created, no files written, no atomic swaps performed
• Idempotent and safe: can run repeatedly to refresh the plan
• Output should be sufficient for a human reviewer to authorize execution
• Same exit codes as `check` (0 = ready, 2 = warnings, 1 = preconditions not met)
• Reads fstab, mount state, kernel version, etc., the same way the live commands do, so the plan reflects what `migrate` would actually do on this system right now

Acceptance criteria

• `atomic-rollback migrate --dry-run` runs without modifying the system
• Output enumerates all 10 migration steps with concrete derived values
• Output includes the BOOTS gate that would run after each step
• `atomic-rollback setup --dry-run` covers the lighter setup path equivalently
• VM verification: dry-run on a fresh Fedora 43 btrfs VM produces a complete plan, then a real `migrate` executes the same operations in the same order

Milestone

0.5.0