feat(e2e): compose test software as a container layer instead of runtime install

[hanthor]

Motivation

rpm-ostree install --apply-live fails on images that deliberately lock runtime layering: bluefin-lts ships rpm-ostreed.conf with LockLayering=true (projectbluefin/bluefin-lts#492, shipped in projectbluefin/bluefin-lts#509). The e2e harness currently layers the common suite's shell tools at runtime inside the booted VM, which breaks against such images. Per maintainer direction, the harness now composes the test software as a container layer at build time — following the pr-e2e.yml pattern in bluefin-lts (Containerfile FROM base + RUN, pushed to GHCR with a run-scoped tag).

Compose flow

1. New compose job in the reusable e2e.yml (runs after the matrix resolve, before the suite jobs; packages: write):
   • checks out container/e2e-overlay/ + scripts/compose-e2e-image.sh at inputs.test_ref
   • scripts/compose-e2e-image.sh builds container/e2e-overlay/Containerfile with --build-arg BASE_IMAGE=<inputs.image> and pushes ghcr.io/<owner>/testsuite-e2e:run-${GITHUB_RUN_ID}
   • exports the composed ref as a job output
2. Suite jobs boot needs.compose.outputs.image || inputs.image (GHCR login added before the pull, since fresh run-scoped packages default to private).
3. The overlay installs the tools the common suite validates — zsh fish fzf bat eza fd-find ripgrep starship (container/e2e-overlay/packages.list) — best-effort per package, mirroring the old step's warning-on-missing tolerance, and runs ostree container commit when applicable.
4. Summary and screenshot naming (IMAGE_SLUG, gh-pages URL, artifact metadata) keep using the raw input image so run-scoped tags don't leak into artifact names.

Fallback toggle

• compose_image workflow input (default true), or repository variable E2E_COMPOSE_IMAGE=0, disables composing.
• A compose-job failure is non-fatal (continue-on-error + warning): suite jobs automatically fall back to the raw image and the legacy runtime-install path.

Runtime-install sites replaced / kept

• Replaced: e2e.yml "Install shell tools for common suite" — the sudo rpm-ostree install --apply-live / dnf install calls inside the VM (the feat(common): add Bluefin-specific GSettings override validation #492 offender). Kept only as the legacy fallback step; on the composed path it becomes a verification-only step.
• Deliberately left on the old path:
  • scripts/install-kde-webdriver.sh (KDE suites) — dnf/source-build inside the VM; ABI-tied to the SUT per its own documented rationale, out of scope here.
  • tests/dx distrobox dnf install — runs inside a mutable container, unaffected by LockLayering.
  • Runner-container microdnf patching and Flatpak preloads — container/Flatpak operations, not host layering.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KSjBPVDcnK71WveusaK7Nc

---

Generated by Claude Code

[hanthor]

Holding this one deliberately while merging the other four testsuite PRs in this batch.

ghost-lab is red here, but it's red on every open PR in this repo — #740, #741, #745, #746, #747, #748, #749 — including pure-docs changes that touch nothing the lab exercises. The check reports from a self-hosted Argo instance at 192.168.1.102:2746, which is unreachable outside the lab network. It's broken infrastructure, not a signal about any of these diffs. It's also not a required check: the main — merge queue ruleset requires only Lint & syntax, Behave dry-run, and pytest, all three of which pass here.

So I've queued #746, #747, #748 and #749, which are docs and test-only changes.

This PR is different and I'd rather not merge it on a red lab. "compose test software as a container layer instead of runtime install" changes how the e2e suite builds its test images — which is precisely what ghost-lab validates end to end. The three required checks are static (lint, a behave dry-run, pytest); none of them actually boots the composed image. Merging this specific change while the only check that would catch a regression is down means shipping it unverified.

Two ways forward, whichever is easier:

1. Bring the lab back and let ghost-lab run this PR for real.
2. If the lab is going to be down for a while, someone runs the composed-layer path manually once and posts the result here, and we merge on that evidence.

Worth fixing the reporting either way: a check that has been failing on 100% of PRs for days is indistinguishable from a check that's finding real bugs, and right now it's training everyone to ignore it. If the lab is expected to be offline, the reporter should skip or report neutral rather than fail.

[castrojo]

Approved by @castrojo for Hive auto-merge on green CI.