feat(ci): reuse immutable SHA-addressed build artifacts

User Story

As a release engineer, I want merge-queue E2E, Release Dev E2E, and Linux packaging to consume one immutable artifact set for a commit SHA, so that the artifacts tested before merge are the artifacts later packaged and released.

Problem Statement

CI currently produces overlapping run-scoped artifacts. Merge-queue E2E receives prebuilt CLI and gateway binaries, while Release Dev E2E can rebuild workspace binaries and packaging has separate producers. There is no durable, digest-verified artifact manifest that consumers can resolve by source SHA.

Impact / Why This Matters

This divergence can hide failures that depend on the binary delivery path, including the rootless Podman E2E discrepancy. Rebuilding increases CI time and makes it harder to establish which exact artifact was tested and packaged.

Proposed Design

For trusted merge-group and main flows, CI resolves one immutable Linux artifact manifest by source SHA. A miss builds and publishes the required artifacts; a hit verifies source metadata and digests before reuse. E2E and Linux packaging consume resolved artifacts without source-build fallback. The manifest is published only after its complete artifact set is available.

Acceptance Criteria

• A complete Linux CLI, gateway, supervisor, and VM-driver artifact manifest can be resolved by source SHA and verifies per-artifact digests.
• Merge-queue and Release Dev rootless Podman E2E use the resolved CLI and gateway artifacts with no workspace-build fallback.
• Linux DEB, RPM, and Snap packaging consumes digest-verified resolved binaries.
• Invalid, incomplete, or source-SHA-mismatched manifests fail closed.
• Publication retains provenance sufficient to identify source SHA, artifact digest, and build workflow.

Alternatives Considered

• Continue using workflow-run-scoped GitHub Actions artifacts: cannot reliably share across merge-queue and post-merge workflows.
• Rebuild in every consumer: preserves current behavior but does not prove tested and released binaries match.
• Use mutable tags alone: does not provide an immutable, auditable artifact identity.

Agent Investigation

The existing Docker build workflow already creates Linux binary artifacts and SHA-tagged images. Branch E2E downloads run-scoped CLI/gateway artifacts, whereas Release Dev invokes the shared E2E workflow without artifact inputs. Release Dev packaging has separate binary producers.

Start by inspecting the existing Docker build workflow, branch E2E artifact downloads, the shared E2E workflow, and Release Dev packaging producers. Trace how artifacts are currently built and passed between these workflows, then define the SHA-keyed manifest and verification flow. Done means the listed E2E and Linux packaging consumers use complete, digest-verified artifacts and fail closed for invalid or mismatched manifests.