[Feature]: Manifest-driven integration CI matrix + prebuilt stack images on GHCR #14

User Story

As an interCEde CI maintainer,
I want one manifest-driven integration workflow and prebuilt backend images,
So that adding a stack is a stacks.yml entry (no workflow edits) and PR CI pulls images instead
of spending 5–10 min rebuilding RPM-based images per job.

Feature Description

Consolidation of the three harmonized prototype stacks (IC-ADR-002 §3, §5):

1. Flesh out integration.yml from the scaffold skeleton: a matrix job reads stacks.yml
   and emits the {stack × config × version} JSON; per-stack jobs run
   docker compose … up --wait → pytest -m "<markers>" --stack=<id> --config=<name>
   (or compose exec for exec_in_container stacks); fail-fast: false; on failure upload
   docker compose logs + backend log dirs as artifacts. Reusable via workflow_call from
   ci.yml, required for merge.
2. build-images workflow → GHCR: build and push
   ghcr.io/diracgrid/intercede-testenv/{arc,slurm,htcondor-ce}:<version> when Dockerfiles or
   pinned ARGs change, plus a weekly rebuild for base-image updates. PR CI pulls by digest.
   Daemons foreground under a minimal supervisor — never systemd (§3).

Definition of Done

• integration.yml generates its matrix from stacks.yml; the three bespoke prototype
  workflows are deleted
• Each stack runs as its own job; failure uploads compose + daemon logs as artifacts
• build-images workflow pushes pinned-ARG images to GHCR; PR CI pulls, never builds
• Integration workflow is workflow_call-reusable and required for merge
• Adding a stack = manifest entry + files (verified by adding no workflow lines for one stack)

Alternatives Considered

• Per-stack bespoke workflows (status quo of the prototypes) — O(stacks) workflow maintenance,
  drift between them; rejected by IC-ADR-002 §5.
• Rebuilding images in every PR job — 5–10 min × jobs wasted; rejected by §3.
• One mega-compose job — shared fate, poor attribution; rejected (ADR Rejected Ideas).

Related Issues

Additional Context