Execute workflow email steps from their template relation

[vladbisceanu]

Delivers: Make SEND_EMAIL execution use the workflow step template relation as the single template authority. API-created workflows with templateId on the step and recipient-only JSON config must execute the same way as dashboard-created workflows; existing configs that also duplicate templateId remain compatible.

Done when: a regression test builds the API-valid step shape, drives the real workflow execution seam, and proves the email step completes. The production opt-in repro must turn green on a new exact pinned image without editing the live workflow.

Read the design and operating rules in parent epic #9 before starting.

[vladbisceanu]

Adversarial contract review narrowed the hotfix to the runtime mismatch:

• The step relation is the template authority at runtime. JSON config keeps recipient options; an old duplicate templateId is accepted for compatibility but ignored by execution.
• Dashboard add/insert keeps its existing provisional-step flow. Enforcing a relational template during creation broke that flow; enforcing it only at activation exposed the existing non-atomic activation race. Those broader workflow-validity changes are outside this production hotfix.
• The regression creates the API-valid recipient-only step shape with a relational template, executes it, and asserts completed execution state, the persisted email binding and recipient, and the queue call.
• A compatibility test puts a different template ID in JSON and proves the relation wins.

Production proof will use a fresh synthetic event against the unchanged live workflow. API and worker must first read back the same new image digest. Existing failed executions stay failed and are evidence, not retry candidates.

[vladbisceanu]

Production proof — 2026-08-28 UTC

• fix(workflows): execute email steps from template relation #19 merged at 62ee1a1480e61b8fb52f56617f555ba57f037d18; paired upstream PR: fix(workflows): execute email steps from template relation useplunk/plunk#472.
• Immutable image: ghcr.io/vladbisceanu/plunk@sha256:baadf1eb12b6daa1aed1d95c91073c412982aa9f5ab0f7a97c47acaeafd9a9a1. OCI source and revision labels read back to this repository and exact merge SHA.
• Railway API f9f8320f-c27d-4adf-8f62-048d74c02e43, worker 8df032dc-680d-4eab-823a-4ee0c8c67a48, and dashboard 4161d0fe-b48e-4392-9c98-03a8ad20b0f9 each report SUCCESS, one running replica, and the exact digest. Public API health and dashboard return 200.
• The unchanged live confirmation workflow received a fresh /v1/track request and completed. Immediate contact readback was unsubscribed/pending; the confirmation email arrived; hosted confirmation changed it to subscribed; the welcome email then arrived with both RFC 8058 headers.
• The hosted unsubscribe changed the contact back to unsubscribed. A separate migrated-unsubscribed synthetic was rejected by the real marketing template with 400 and remained unsubscribed. An SES simulator bounce flipped a newly subscribed proof contact to unsubscribed.
• All three synthetic contacts were deleted after proof. No live workflow was edited.