Show each action-flow email send in work order activity feed (match Resend history)

When the same action-flow email action runs multiple times on one inspection, Resend shows every send, but the work order activity feed usually shows only one row—CS needs Attik to reflect each send (or an equivalent audit trail) without cross-checking Resend alone.
Exact presentation (one row per execution, per Resend message id, or an expandable card listing sends) is a product decision.

FlowActionResult documents are effectively one per (flow action × job) because Bull work is keyed with a stable job id (flow_${flowId}-action_${actionId}-inspection_${jobId}) from src/util/functions/actionFlows/flowEventTriggerer.ts, and completion handlers upsert by that id—new runs overwrite the same Mongo document instead of appending.
The activity UI loads flow-action results via GET flow-action/result (src/routes/flowActionResults.ts, FlowActionResult in src/models/flowSchema.ts); src/components/activityFeed/ActivityFeed.tsx requests flow-action/result—the feed is not “hiding” rows so much as older executions often no longer exist as separate documents.
Email worker logic may still push into emailResults within a single completion path (src/events/bullmq/emailWorker.ts); multiple separate queue runs still collapse to one parent result id.

Backend (attik-backend)

src/util/functions/actionFlows/flowEventTriggerer.ts — job id / deduplication behavior.
src/events/bullmq/flowWorker.ts — FlowActionResult.findOneAndUpdate keyed on job id.
src/events/bullmq/emailWorker.ts — how emailResults arrays are updated.
src/routes/flowActionResults.ts — API shape for listing and retry/resend.

Frontend (attik-frontend)

src/components/activityFeed/ActivityFeed.tsx, ActionFlowBlock.tsx, ActionStatusCard patterns—may need to render multiple executions or nested emailResults if the persistence model changes.

Attik