PRD: Bind WhatsApp group to runtime image (template→image mapping)

[atomdbc]

Problem

We need each WhatsApp group to run a different on-demand container runtime (different tools, egress policy, configuration). Today the system has templates/bindings, but there is no explicit, auditable mapping from a provider_group_id to a concrete runtime image (or an image-resolving template version).

Goal

Persist and expose a group → runtime image (or template-version that resolves to an image) mapping that the runtime router can use for on-demand execution.

Scope

• Define the canonical mapping and constraints (e.g., 1 active binding per group).
• Add DB schema + repository methods.
• Add API surface to read the resolved runtime target for a group.

Proposed model (one of these, choose and implement)

• Option A (direct): bindings.runtime_image_ref (e.g., kuuna/client:2026-04-22-...).
• Option B (indirect): bindings.template_version_id and a separate template_builds table where a successful build yields image_ref.

Acceptance criteria

• Given a provider_group_id, the backend can resolve exactly one active runtime target.
• The mapping is queryable and auditable (created_at/updated_at/updated_by).
• Clear error behavior when:
  • no binding exists
  • binding exists but no built image exists
  • binding is inactive

Out of scope

• Actually building images.
• Running containers.

Notes

• Keep it compatible with the existing “binding status: Active” lifecycle.