fix(triggers): compute nextFireAt in workflow-trigger-service so schedule triggers fire

[jonwiggins]

Bug

Schedule triggers created through workflow-trigger-service never fired.

There are two creation paths for workflow_triggers rows:

• workflowService.createWorkflowTrigger / taskConfigService.createTaskConfigTrigger — used by the unified POST /api/tasks/:id/triggers route — compute nextFireAt from the cron expression at creation.
• workflow-trigger-service.createTrigger — used by the legacy POST /api/jobs/:id/triggers route — inserted the row without nextFireAt.

The schedule poller (getDueScheduleTriggersAll) only selects rows with next_fire_at <= now, so a schedule trigger created via /api/jobs/:id/triggers was perpetually invisible to the poller and never fired. updateTrigger (behind PATCH /api/jobs/:id/triggers/:triggerId) had the same gap: changing the cron expression or re-enabling a schedule trigger never (re)computed nextFireAt, so a trigger disabled-then-re-enabled through that route also went dead.

Affected routes: POST /api/jobs/:id/triggers, PATCH /api/jobs/:id/triggers/:triggerId.
Unaffected: unified POST/PATCH /api/tasks/:id/triggers (standalone + repo-blueprint) and /api/task-configs/:id/triggers.

Fix

• Extracted computeNextFire into apps/api/src/utils/cron.ts and reuse it from workflow-service.ts, task-config-service.ts, and workflow-trigger-service.ts — the first two previously each had their own private copy, so this de-dupes the cron parsing rather than adding a third copy.
• workflow-trigger-service.createTrigger now stamps nextFireAt for enabled schedule triggers.
• workflow-trigger-service.updateTrigger now recomputes nextFireAt on cron change / re-enable and clears it on disable, mirroring the other two services (it now also short-circuits to null for a missing id before touching the DB, same as updateTaskConfigTrigger).

Tests

• apps/api/src/services/workflow-trigger.int.test.ts — the test that explicitly pinned the buggy behavior ("createTrigger does not compute nextFireAt … never fires") is flipped into a positive one: a schedule trigger created via the service gets a computed nextFireAt, becomes due, and the worker check fires it (run created, lastFiredAt stamped, nextFireAt advanced). Added an updateTrigger test covering recompute-on-re-enable, recompute-on-cron-change, and clear-on-disable.
• apps/api/e2e/scheduled-trigger.e2e.test.ts — the legacy-route section pinned nextFireAt = null; it now asserts the legacy route computes nextFireAt like the unified route. The null-nextFireAt due-query case is preserved by nulling the column via direct SQL, since the API can no longer produce that state.
• apps/api/src/services/workflow-trigger-service.test.ts — unit coverage for the new create/update nextFireAt behavior; existing update mocks adjusted for the new existence check.

Verification

• cd apps/api && npx tsc --noEmit — clean
• npx vitest run (apps/api unit) — 123 files, 2172 tests passed
• npx vitest run --config vitest.integration.config.ts src/services/workflow-trigger.int.test.ts — 12/12 passed, twice
• npx vitest run --config vitest.e2e.config.ts e2e/scheduled-trigger.e2e.test.ts — 4/4 passed, twice
• pnpm format:check — clean