Automatically run release validation tests in CI against multiple base systems

[yfyf]

Currently we manually run release-validation tests, but this is easy to forget and there is no visibility to the team about the outcomes.

Since they are "expensive" to run (take a long time), running them on each push/PR to main is maybe too extreme, but running them on each push to release/* is warranted since it indicates we intend to deploy the tree in the somewhat near future.

CI also allows us to easily run the release-validation tests against multiple base system images. Since we have not yet decided on the "archetypal skeletons", for now this just hard-codes base system versions to some "ancient" ones + the previous (latest released) version.

Manually started CI run: https://github.com/dividat/playos/actions/runs/21177566028 🟢

[yfyf]

Discovered some flakiness in release-validation tests (mostly in CI), which seems to be fixed with
776f427 and 606eaaf, except for a strange navigation failures that seem to only happen on 2024.7.0 and which I cannot reproduce locally unfortunately. Trying to find the root cause, probably also timing related. Can open a separate PR for these.

[yfyf]

There's probably some video driver compatibility with QEMU issue in 2024.7.0, causing partial/very slow screen refresh.

The OCR texts indicate that both bits from the both the Controller main (Information) page and the Status Page are simultaneously visible on the screen - something that should not be possible.

For example: https://github.com/dividat/playos/actions/runs/21176096534/job/60905229495#step:4:4611

Update State  # <- this is only visible in System Status page
RebootRequired

Machine ID # <- this is only visible in Information page
f414-cca8-3125-48d2-9689-ebf2-87fb-67e0

Possible solutions:

1. Wait even longer after navigate_to_system_status() for the screen to refresh
2. Exclude 2024.7.0 from the testing matrix, since this seems to only affect this release

I tried option 1 in d1d70d6 and it seems to be sufficient, which amounts to an extra ~5 second sleep, but I don't think it's reasonable to penalize all other versions because of one flaky one.

So instead for now applying option 2 in f01ad6f, if we discover the same issues for some skeleton, we can go back to option 1.