Triggers: let a cron/webhook trigger run a durable pipeline, not just the 4 canned actions

[serge-ivo]

Gap found assessing the lead-finder (2026-08-02). Instance triggers can fire on cron/webhook, but the action is limited to `create_task | add_knowledge | log_event | sync_connector` (`lib/triggers.ts`). None of them can run a deterministic multi-step pipeline (e.g. a Places grid sweep) or write into a collection. So "on a schedule, run this pipeline and store results" has no native path — you must hand-write a first-party Cloudflare Workflow (behind the closed `workflow` union) or an external Worker.

Ask

Give cron/webhook triggers a way to drive durable work:

• A run_workflow (or run_pipeline) trigger action that fires a durable Workflow for the instance (escapes the 30s DO limit; resumable — same machinery as JOB_APPLY/CODING_SESSION).
• Decouple from the closed workflow union so a new pipeline can be registered as data/code, not a monorepo edit (ties to Tier-2, [3P] Tier-2: sandboxed creator code via Dynamic Workers (CRITICAL PATH) #52).
• Optionally an insert_record trigger action (webhook → collection) for the simple ingest case.

Acceptance

• A cron trigger can kick a resumable per-instance pipeline that reads/writes the instance's collections.
• Adding a new pipeline type doesn't require editing the capability union.

Relates to #58, #52.

[serge-ivo]

Shipped in 9e47ee1.

Two new trigger actions in lib/triggers.ts:

• run_pipeline — a cron/webhook trigger now kicks the durable, resumable PipelineRunWorkflow for the instance via the existing startPipelineRun helper (the hook its own comment had reserved for Triggers: let a cron/webhook trigger run a durable pipeline, not just the 4 canned actions #92). The pipeline is resolved by name from instance config (config.pipeline or payload.pipeline) through loadPipeline — it's data, not the closed workflow union — so adding a new pipeline type never touches the capability union. Escapes the 30s DO limit and reads/writes the instance's collections.
• insert_record — webhook → collection ingest: posts the payload (an explicit record/data object, else the payload minus the collection routing key) to the DO's POST /collections/:name/records.

Both ACs met: ✅ a cron trigger kicks a resumable per-instance pipeline that reads/writes collections; ✅ adding a new pipeline type doesn't require editing the capability union (pipelines are config data).

Wired end-to-end: action union + ACTIONS set + assertTriggerAction message + parseConfig whitelist (pipeline/collection) + successMessage. The create route (assertTriggerAction) and MCP create_instance_trigger accept the new actions as-is. +6 unit tests; api typecheck + pipeline/trigger suites green.

Follow-up (not blocking): the console trigger form (SettingsTab action dropdown) still lists only the original 4 — adding run_pipeline/insert_record there needs dedicated pipeline-name / collection config inputs so it can't create a broken trigger. Filed as a UI follow-up; the API/MCP path is fully usable today.