fix(workflows): scope dunning backfill to its own flow via targetWorkflowId

Address review on #764: backfillDunningRuns emitted invoice.sent without a
target, so enabling dunning would also enroll every historical open invoice
into any custom invoice.sent flow. Pass the enabled flow's id through to
emitWorkflowEvent so the backfill only touches dunning. Also note the
computeWakeAt both-fields (untilVar + delay) behaviour change in its comment.

backend/src/routes/adminWorkflows.js

@@ -256,10 +256,12 @@ router.patch('/:id/enabled', requirePermission('workflows.manage'), async (req,
     await db('workflows').where({ id }).update(patch);
     // Turning dunning ON enrolls existing open/unpaid invoices (anchored to
     // their due date) so it starts chasing current debtors, not only invoices
-    // sent after enabling (#750). Best-effort — never fail the toggle over it.
+    // sent after enabling (#750). Scoped to this flow's id so the backfill only
+    // enrolls dunning, not any custom invoice.sent flow. Best-effort — never
+    // fail the toggle over it.
     if (enabled && wf.builtin_key === 'invoice_dunning') {
       try {
-        const n = await require('../services/workflows').backfillDunningRuns();
+        const n = await require('../services/workflows').backfillDunningRuns(id);
         require('../utils/logger').info('[workflow] dunning enabled — enrolled existing invoices', { enrolled: n });
       } catch (e) {
         require('../utils/logger').warn('[workflow] dunning backfill failed', { error: e.message });