[DEFER] Parallelize release image publish with matrix job

[mark-e-deyoung]

Summary

Release workflow builds/pushes supragoflow-build and supragoflow-dev sequentially in one job. This is simple, but it extends release latency and underutilizes CI parallelism.

Why this matters

As release pipeline work grows (extra validation, additional platforms), sequential image publishes become a scalability bottleneck.

Proposed direction

Refactor release.yml to use a matrix job for Dockerfile/image targets:

• Shared setup once (checkout, QEMU/buildx, GHCR login, versions env).
• Matrix entries for docker/Dockerfile.build and docker/Dockerfile.dev.
• Preserve current tag semantics (explicit release tag only).

Acceptance criteria

• Release still publishes the same two images with same tags.
• Workflow runtime decreases or remains neutral with no loss of correctness.
• Failure output clearly identifies which image target failed.
• Policy constraints for canonical release tags remain unchanged.

Risk notes

• Keep matrix definition readable to avoid maintenance overhead.
• Ensure build args remain correct per image type.