fix(webapp): batch items bypass the mollifier gate

Batch triggers crash with HTTP 500 "Foreign key constraint violated on
the constraint BatchTaskRunItem_taskRunId_fkey" whenever the mollifier
gate is active. The crash chain:

1. batchTriggerV3 generates a run id per item, calls
   `triggerTaskService.call` with `options.batchId` set.
2. The mollifier gate trips, the item is buffered, the mollify response
   returns a stripped run shape `{ id, friendlyId, spanId }` with no
   PG row.
3. batchTriggerV3 then tries `prisma.batchTaskRunItem.create({
   taskRunId: result.run.id, ... })` — the FK to TaskRun.id fails
   because no row was written.

The proper fix requires both ends: skip the join-row create at
trigger-time AND create it on the drainer-side materialise. The
drainer fix is non-trivial (the drainer / replay PR territory, not
the dashboard PR) and the snapshot already carries
`batch: { id, index }` so it has the info — but until that's wired
through to a `BatchTaskRunItem.create` call on materialise, skipping
trigger-time would silently lose the batch <-> run link forever and
break batch progress reporting + `batchTriggerAndWait` parent
resumption.

Short-circuit the gate when `options.batchId` is set so batch items
always go straight to PG. Batch triggers lose the burst-protection
benefit of the mollifier; single triggers and triggerAndWait are
unaffected. Removing this bypass is the natural follow-up once the
drainer-side BatchTaskRunItem path lands in the appropriate earlier PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/runEngine/services/triggerTask.server.ts

@@ -386,22 +386,49 @@ export class RunEngineTriggerTaskService {
                 // `evaluateGate` can also override the gate-on check (the
                 // default reads `env.TRIGGER_MOLLIFIER_ENABLED`, which is "0"
                 // in CI where no .env file is present).
-                const mollifierOutcome: GateOutcome | null = this.isMollifierGloballyEnabled()
-                  ? await this.evaluateGate({
-                      envId: environment.id,
-                      orgId: environment.organizationId,
-                      taskId,
-                      orgFeatureFlags:
-                        (environment.organization.featureFlags as Record<string, unknown> | null) ??
-                        null,
-                      options: {
-                        debounce: body.options?.debounce,
-                        oneTimeUseToken: options.oneTimeUseToken,
-                        parentTaskRunId: body.options?.parentRunId,
-                        resumeParentOnCompletion: body.options?.resumeParentOnCompletion,
-                      },
-                    })
-                  : null;
+                //
+                // Batch items bypass the mollifier gate entirely.
+                //
+                // The mollify path returns a stripped run-shape `{ id,
+                // friendlyId, spanId }` with no PG row written. Batch
+                // tracking relies on `BatchTaskRunItem`, a join row whose
+                // `taskRunId` column has a NOT NULL FK to `TaskRun.id` —
+                // creating that join at trigger-time (in
+                // `batchTriggerV3.server.ts:871`) fails with FK violation
+                // for any mollified item, and skipping it at trigger-time
+                // would silently drop the batch↔run link forever because
+                // the drainer's materialise path doesn't (yet) create
+                // `BatchTaskRunItem`. Either side alone is wrong:
+                //   - skip at trigger-time only → batch progress
+                //     under-reports forever, `batchTriggerAndWait` parent
+                //     stays parked
+                //   - mollify at trigger-time only → FK violation, 500
+                //
+                // The proper end state is a drainer-side
+                // `BatchTaskRunItem` create-on-materialise (the snapshot
+                // already carries `batch: { id, index }` so the drainer
+                // has the info). That belongs in the drainer / replay PR,
+                // not here. Until that lands, batch triggers pass-through
+                // — they lose the burst-protection benefit, but the path
+                // works end-to-end.
+                const skipMollifierForBatch = !!options.batchId;
+                const mollifierOutcome: GateOutcome | null =
+                  this.isMollifierGloballyEnabled() && !skipMollifierForBatch
+                    ? await this.evaluateGate({
+                        envId: environment.id,
+                        orgId: environment.organizationId,
+                        taskId,
+                        orgFeatureFlags:
+                          (environment.organization.featureFlags as Record<string, unknown> | null) ??
+                          null,
+                        options: {
+                          debounce: body.options?.debounce,
+                          oneTimeUseToken: options.oneTimeUseToken,
+                          parentTaskRunId: body.options?.parentRunId,
+                          resumeParentOnCompletion: body.options?.resumeParentOnCompletion,
+                        },
+                      })
+                    : null;
 
                 // When the gate says mollify, write the engine.trigger input
                 // snapshot into the Redis buffer and return a synthesised