fix(comment-automation): validate flowId exists before saving a reply

[rawdaymx]

Fixes #1228.

None of CommentAutomation's 8 write methods (Messenger, Instagram, Threads, TikTok — create/update) validated that privateReply.value or publicReply.value pointed at a real flow when the reply type is "flow". AutomatedResponse (Keywords) already does this via flowService.exists before saving (automated-response/service.ts); this table never did, for either reply field or any of its write methods.

A stale or mistyped flowId saves silently and the automation looks active in the UI, but every trigger fails at delivery time with a bare FlowVersion not found (worker's detectFlowVersion, apps/worker/src/lib/db.ts) — that failure is never surfaced back to the person who configured the automation.

Not a tenant-isolation issue

We checked this specifically before treating it as a normal bug: detectFlowVersion scopes its lookup to the triggering conversation's own workspaceId in every case, for both privateReply (private-reply.ts) and publicReply (public-reply.ts). A foreign flowId can never execute cross-tenant — it just fails closed with "not found." That's why this is a validation gap, not a security report.

Change

Adds a private assertFlowReplyExists(workspaceId, field, reply, tx?) helper, mirroring the check AutomatedResponse already runs, and wires it into all 8 write methods:

• createMessenger / updateMessenger — privateReply + publicReply
• createInstagram / updateInstagram — privateReply + publicReply
• createThreadsAutomation / updateThreadsAutomation — publicReply only
• createTiktokAutomation / updateTiktokAutomation — publicReply only

(Threads and TikTok fix privateReply to {type: "none"} and don't let the caller set it, so only their publicReply needs covering.)

Verification

packages/business/__tests__/comment-automation-write-methods.test.ts, 7 new cases added to the existing suite:

Test Files  1 passed (1)
     Tests  17 passed (17)

ultracite check and check-types are clean.