Add grubby default checks for kernel upgrade test

tests/cmc-upgrade-kernel-test.md

@@ -37,6 +37,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
 - On Red Hat-family systems, verify `kernel-devel-<target>` and `kernel-headers-<target>` availability (or documented distro-equivalent package names where applicable).
 - The first kernel upgrade attempt must not use the latest kernel in the filtered candidate list; reserve the latest kernel for the final kernel-upgrade stage.
 - When upgrading kernel versions, also upgrade/install the matching development/header packages for that same version.
+- On Red Hat-family systems that use `grubby` (including Oracle Linux), explicitly set the selected kernel as the default before rebooting, then verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-<target>` path. If the default does not match, stop before reboot as blocker-fail.
 - After each kernel upgrade and reboot, verify running kernel version and installed dev/header package versions all match.
 - If kernel and dev/header package versions are mismatched at any point, stop immediately as blocker-fail and do not continue with remediation by assumption.
 - Before any kernel candidate discovery step on any distro, force a fresh package metadata refresh on the live host before evaluating available kernel builds. Use the distro's normal refresh command for the installed package manager (for example `dnf makecache`, `yum makecache`, or `zypper refresh`). For APT-based distros, use a hard APT refresh so stale or empty package-list files are rebuilt: `rm -rf /var/lib/apt/lists/* && apt-get clean && apt-get update`. If the refreshed view differs from a prior result, trust the refreshed live metadata and record that the earlier view was stale.
@@ -127,6 +128,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
 - [ ] 36. Select the first-upgrade target from the filtered candidate list.
 - [ ] 37. Verify matching dev/header packages are available for the first-upgrade target.
 - [ ] 38. Install the first-upgrade kernel and matching dev/header packages, then reboot.
+- [ ] 38a. On Red Hat-family systems with `grubby` including Oracle Linux, set the first-upgrade kernel as the grubby default and verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-<target>` path before reboot.
 - [ ] 39. Query vCenter guest-tools again for the live clone IP after reboot.
 - [ ] 40. SSH to the rebooted clone and verify kernel plus dev/header package versions match the selected first-upgrade version.
 - [ ] 41. If versions do not match exactly, stop as blocker-fail.
@@ -140,6 +142,7 @@ Validate CMC behavior across staged kernel upgrades on a cloned VM, including re
 - [ ] 49. Select the latest-upgrade target kernel from the filtered candidate list.
 - [ ] 50. Verify matching dev/header packages are available for the latest-upgrade target.
 - [ ] 51. Install the latest-upgrade kernel and matching dev/header packages, then reboot.
+- [ ] 51a. On Red Hat-family systems with `grubby` including Oracle Linux, set the latest-upgrade kernel as the grubby default and verify `grubby --default-kernel` returns the selected `/boot/vmlinuz-<target>` path before reboot.
 - [ ] 52. Query vCenter guest-tools again for the live clone IP after reboot.
 - [ ] 53. SSH to the rebooted clone and verify kernel plus dev/header package versions match the selected latest-upgrade version.
 - [ ] 54. If versions do not match exactly, stop as blocker-fail.
@@ -215,6 +218,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
 36. Select first-upgrade target from filtered candidate list (same major; same minor preferred), ensuring it is not the latest candidate.
 37. Verify matching dev/header packages for the selected first-upgrade target are available.
 38. Install selected first-upgrade kernel and matching dev/header packages, then reboot.
+   - On Red Hat-family systems with `grubby`, run `grubby --set-default /boot/vmlinuz-<selected-kernel>` and verify `grubby --default-kernel` returns that exact path before rebooting.
 39. Query vCenter guest-tools again for the live clone IP after reboot.
 40. SSH to the rebooted clone via the live vCenter IP and verify running kernel and installed dev/header package versions match the selected first-upgrade version.
 41. If versions do not match exactly, stop as blocker-fail.
@@ -230,6 +234,7 @@ The `Execution Checklist` above is the authoritative run ledger. Use the procedu
 49. Select latest-upgrade target kernel from the filtered candidate list (same major required; same minor preferred).
 50. Verify matching dev/header packages for the selected latest-upgrade target are available.
 51. Install selected latest-upgrade kernel and matching dev/header packages, then reboot.
+   - On Red Hat-family systems with `grubby`, run `grubby --set-default /boot/vmlinuz-<selected-kernel>` and verify `grubby --default-kernel` returns that exact path before rebooting.
 52. Query vCenter guest-tools again for the live clone IP after reboot.
 53. SSH to the rebooted clone via the live vCenter IP and verify running kernel and installed dev/header package versions match the selected latest-upgrade version.
 54. If versions do not match exactly, stop as blocker-fail.