Create DM automation

Per-day creator-outreach caps + run window. Stored into Automations.schedule JSONB. Same shape as the existing portal payload — keeps the portal and Public API agreeing on schema.

Outreach-paradigm recipient inclusion. Three mutually-exclusive modes (cf. INTERNAL-design-review.md §11A):

• lists mode — list_upload and/or lists_selected populated
• filters mode — filters populated (dynamic by attribute)
• crm_group mode — crm_group_id populated (saved predicate)

The validator below rejects any request that mixes modes. The creator_source_type discriminator written to config is derived from which mode is set — callers don't need to set it explicitly.

Outreach-paradigm recipient exclusion. Mirrors creators_to_omit in the legacy DB column / frontend payload, plus the boolean exclude_previously_messaged flag from the portal's Exclude Creators panel.

Initial-outreach addons — text + optional image / product card / spark_code form. ALL items are sent immediately together when the automation engages a creator. Use follow_ups for delayed steps.

Delayed follow-up steps — same shape as TC.

DM type-specific config blob, populated based on mode.

CORE-4857 — enable AI personalization of the initial-outreach DM.

When set on POST /automations/dm, the send engine rewrites the DM body per creator using the [Block] tokens in your message text: Content Discussion and Product Discussion are AI-generated from the creator's own signals, while Product Description / Selling Points / Offer are the fixed strings you provide here. A creator with too little signal to personalize receives fallback_message instead.

All copy fields are stored verbatim — there is NO server-side AI at create time — so the create is deterministic and idempotent, and the send path's reuse hash stays stable. Resolve the product blocks beforehand via POST /personalization/product-blocks and preview any creator via POST /personalization/preview so what ships is what you approved.

Canonical write-endpoint response. Replaces the v1 AutomationResource (which mirrored the legacy single-shape body). Now reflects the four-type taxonomy — automation_type is the public-API type, not the DB string. The DB string is in _internal_type for debugging only.