Adds ai_flow_schedules table for scheduled AI flow triggers

What does this MR do?

This MR partially addresses #594180 and adds flow schedules table for scheduled AI flow triggers.

First MR in a stacked series adding cron-based scheduling for AI flow triggers. This MR is database-only and no application code reads or writes the new table yet. Behavior lands in follow-up MRs.

• Scheduled trigger implementation design (see point 1): #594180 (comment 3642562838)
• DB Design Diagram: #594180 (comment 3642572634)

Why

Ai::FlowSchedule is a standalone entity rather than an extension of Ci::PipelineSchedule, which is too CI-coupled. This follows the precedent of ContainerExpirationPolicy and Packages::Cleanup::Policy, which use their own tables with the shared Schedulable/CronSchedulable concerns. A FlowTrigger can have many FlowSchedules (e.g. daily at 09:00 plus weekly Monday at 15:00), so schedules live in their own table rather than as columns on the trigger.

How

• consecutive_failure_count, last_run_status, and last_run_error on the ai_flow_schedule table will support auto-deactivating a schedule after 3 consecutive failures instead of failing silently, and surface the reason to users.
• duo_workflows_workflows.trigger_flow_schedule_id column: since a trigger will have many schedules, trigger level attribution alone can't tell which specific schedule fired a workflow. This completes the traceability chain for debugging and audit..
• plan_limits column: per-project cap on schedule count that'll be enforced via the Limitable concern in a follow up MR. Every schedule autonomously spawns AI workflow executions, so this count cap complements per schedule rate limiting.

Database Design

Anticipated growth & access patterns (database review)

• Growth (3/6/12 months): driven directly by feature adoption; hard-capped at 10 schedules per project via plan_limits.ai_flow_schedules (default 10). Internal-first rollout means low thousands of rows in the first months; even broad adoption keeps this a small table (one row per schedule, fixed-width columns).
• Reads/writes per hour: reads come from the scheduler worker polling for due schedules (partial composite index on (next_run_at, id) WHERE active = true). The dispatcher (follow-up MR) runs on a ~10-minute jittered cron; even at a conservative 1-minute cadence this stays at ~10,000 reads/hour with 10,000 active schedules. Writes are one row update per execution (run metadata); at ~one run/day per schedule, ~400 writes/hour at 10k schedules.
• Availability risk: low — small fixed-width rows, all lookups indexed, no hot-row patterns; per-project plan limit bounds growth on GitLab.com and Self-Managed alike. The design mirrors ci_pipeline_schedules, which runs at much larger scale.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.