Refactor and upgrade release-validation to perform a double-update

[yfyf]

Note 1: using unsignedRaucBundle from releaseValidation components to ensure that the updated system has passwordless root. Needed for debugging purposes and to be able to cleanly restart the system(s) via TTY. More generally, this ensures that the bundles have the same same "mods" as the release disks.

Note 2: this incorporates the safe-TTY-reboot (606eaaf) from #307, but not the other CI / flakiness patches there. Should be added too, keeping this a draft until then. Rebased on top of main, done.

Note 3: in an ideal scenario, we would check that BASE->PRE reaches UpToDate and only then change latest to NEXT and do the second update, but I can't think of a way to do this that doesn't involve a manual controller restart or an extra reboot (or waiting for 1 hour), so we only check for UpToDate after the second update.

[yfyf]

Ughhh, the double-update fails for older baseSystem versions, because their disks have been created with a persistent data partition that doesn't fit the bundle and fail while the second update is being downloaded.

Need to back-port #300 to earlier releases and rebuild the disks.

Otherwise everything seems to work: https://github.com/dividat/playos/actions/runs/21242598811

[knuton]

Ughhh, the double-update fails for older baseSystem versions, because their disks have been created with a persistent data partition that doesn't fit the bundle and fail while the second update is being downloaded.

Need to back-port #300 to earlier releases and rebuild the disks.

Should we reduce to only last release and see this through and keep an issue for the backporting and subsequent widening of automatic tests?

[yfyf]

Ughhh, the double-update fails for older baseSystem versions, because their disks have been created with a persistent data partition that doesn't fit the bundle and fail while the second update is being downloaded.
Need to back-port #300 to earlier releases and rebuild the disks.

Should we reduce to only last release and see this through and keep an issue for the backporting and subsequent widening of automatic tests?

I'll just backport it. It's easy to do and I would prefer to validate that the release-validation tests do work at least across a few generations, will make it easier to adapt them for the skeletons later on.