Add columns for allowlisting CI/CD variables in flows

What does this MR do and why?

Adds three columns, all boolean DEFAULT false NOT NULL, with no index:

• ci_variables.allowed_in_workloads and ci_group_variables.allowed_in_workloads: owner opt-in for exposing a variable to GitLab Duo Agent Platform workloads.
• p_ci_workloads.protected_ref: whether the workload's source ref was protected.

Nothing reads the columns yet; the follow-up MRs below wire them in. They are only read after the existing (project_id|group_id, key, environment_scope) unique indexes, or on a single workload fetched by (pipeline_id, partition_id).

Migration testing results are posted by the database-testing bot in the comments (each migration takes 3–5 s per database, +0 B; the ALTER TABLE itself is milliseconds because the default is stored in the catalog).

References

• Work item: #602887
• Split of !252729 (the original, now the final MR):

#	Merge request	Base
1	!254470 (merged) Add columns	master
2	!254471 (merged) Parse variables in agent-config.yml	master
3	!254472 Persist source ref protection	1
4a	!254473 Expose allowed_in_workloads on APIs	1
4b	!254474 Settings checkbox	4a
5	!252729 Gate workload variables (feature becomes active)	3, needs 2

Screenshots or screen recordings

Not applicable: schema only.

How to set up and validate locally

1. Run bin/rails db:migrate and confirm the three migrations apply.
2. In Settings > CI/CD > Variables of a project, add a variable: it still saves and behaves as before.
3. In a Rails console, Ci::Variable.last.allowed_in_workloads returns false.
4. Run bin/rails db:rollback:main STEP=3, then bin/rails db:migrate again: both directions succeed.

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.