[Bug] Workflow triggers declared in YAML are never activated — SyncTriggers has no callers

[michaelmcnees]

Summary

Cron / webhook / email triggers declared in a workflow's YAML are parsed and validated but never fire, because the row that the schedulers read from is never written on apply.

Details

• The cron scheduler, webhook handler, and email poller all read triggers from the workflow_triggers table (ListCronTriggers, LookupWebhookTrigger, ListEmailTriggers in internal/server/trigger.go).
• The only function that writes that table is SyncTriggers (internal/server/trigger.go:32).
• SyncTriggers has zero callers in non-test code (confirmed by grep — it appears only in trigger.go, email_trigger.go, and their tests). Neither the apply path (mantle apply → workflow.Save, internal/workflow/store.go) nor GitOps sync (internal/repo/sync/engine.go) calls it.
• Consequently workflow_triggers stays empty under normal use, and declared type: cron|webhook|email triggers do not activate.
• Related: the email poller's Reload() (internal/server/email_trigger.go) is also never called outside tests, so triggers only load at server startup even if the table were populated.

Impact

Any event-driven design is currently broken unless the table is populated out-of-band. Manual runs (mantle run / POST /api/v1/run) are unaffected — which is why the office-assistant MVP (see the MVP issue in this set) deliberately relies on manual runs. But the fuller vision (event-driven "transcript ready" ingestion, an inbound chat bot) depends on triggers actually firing.

Proposed fix

• Call SyncTriggers from the apply path (workflow.Save / the apply command) and from GitOps sync, so applying a workflow reconciles its declared triggers into workflow_triggers (create/update/delete to match the definition).
• Invoke the email poller's Reload() (and equivalent for cron/webhook) after a sync so newly-applied triggers activate without a server restart.
• Add an integration test: apply a workflow with a cron + webhook trigger, assert rows exist and that the scheduler/handler picks them up.

Notes

Git-repo webhooks (/hooks/git/<repo-id>, #16) are a separate, working path and are not affected by this bug.