ci(qualification): run native Linux proof-of-concept pipeline #2976

Description

Run the first end-to-end release qualification pipeline by composing the Linux proof-of-concept scenarios with the native installation profile and shared conformance testsuite.

The proof of concept covers:

• Ubuntu 24.04 with rootful Docker;
• Fedora with rootful Podman and SELinux enforcing;
• Fedora with rootless Podman and SELinux enforcing.

The workflow consumes immutable artifacts produced by the release pipeline, retains qualification evidence tied to those artifacts, and reports one unambiguous qualification conclusion.

N-to-N+1 upgrades and package-manager installation through DEB or RPM are follow-on work. They are deliberately excluded from this proof of concept.

Context

• Parent release pipeline: feat: 0.1.0 release pipeline #2860
• Reusable release artifacts: chore(ci): clean up release pipeline #1683
• Shared driver conformance suite: spike: driver conformance suite for compute drivers #2183
• Linux proof-of-concept scenarios: ci(qualification): add Linux proof-of-concept scenarios #2973
• Installation profile model: refactor(tmachine): separate installation profiles #3419

The initial pipeline validates scenario, installation-profile, and testsuite composition with the native installation profile before package installation and stateful upgrade qualification are added.

Definition of Done

• A manually dispatchable and reusable GitHub Actions workflow accepts an immutable candidate artifact set.
• The workflow runs all three Linux proof-of-concept scenarios from ci(qualification): add Linux proof-of-concept scenarios #2973.
• Each scenario uses the native installation profile and the shared conformance testsuite.
• Fedora qualification fails unless SELinux is enforcing in both rootful and rootless scenarios.
• Candidate binaries and runtime images are downloaded and reused; qualification does not rebuild them.
• Results identify the candidate version, source commit, artifact identities, scenario, installation profile, and testsuite versions.
• Human-readable output, machine-readable results, logs, and scenario diagnostics are retained for each run.
• The workflow exposes a single pass/fail result that the release pipeline can consume as a publication gate.