Support flow versioning for foundational flows

What does this MR do and why?

Adds support for structured flow versioning in the CI job environment variables, enabling Rails to explicitly control which flow config version the AI Gateway uses.

The AI Gateway now supports semantic versioning for flow configs via three new gRPC proto fields on StartWorkflowRequest: flowConfigId, flowConfigSchemaVersion, and flowVersion. The duo CLI already reads the corresponding env vars (DUO_WORKFLOW_FLOW_CONFIG_ID, DUO_WORKFLOW_FLOW_CONFIG_SCHEMA_VERSION, DUO_WORKFLOW_FLOW_VERSION). This MR makes Rails emit those env vars.

Why is this needed?

Multiple GitLab versions communicate with the same AI Gateway. Without version pinning from the client side, a flow config upgrade on the AI Gateway could break older GitLab versions. This gives Rails explicit control over which version each flow uses.

This MR is also done to unblock a discussion here gitlab-org#18785 (comment 3327689139). TL;DR: We want to ship the flow versioning with 19.0 and already point the developer flow to the 2.0.0 version (which we for now point back to a version that is basically the 1.0.0 gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!5459 (merged)). As soon as testing is done for the developer_unstable, we will swap what is behind 2.0.0 so that all customers from 19.0 on will get the improvements.

Key changes

FoundationalFlow model:

• Added flow_version attribute (default '1.0.0', developer flow gets '2.0.0')
• Added resolve_flow_params(reference, project) class method that resolves a flow reference into a params hash (flow_definition, flow_config_id, flow_config_schema_version, flow_version), applying feature flag overrides (duo_developer_next_unstable, fix_pipeline_next)

Callers (ExecuteWorkflowService, CreateAndStartWorkflowService, DuoWorkflowHelpers):

• Each caller merges FoundationalFlow.resolve_flow_params(...) into the params passed to StartWorkflowService

StartWorkflowService:

• Simplified to pure params-in / workload-out — no longer resolves flows or checks feature flags
• Removed resolve_workflow_definition, resolve_developer_workflow, resolve_fix_pipeline_workflow
• Reads flow_definition, flow_config_id, flow_config_schema_version, flow_version directly from params
• New env vars: DUO_WORKFLOW_FLOW_CONFIG_ID, DUO_WORKFLOW_FLOW_VERSION
• DUO_WORKFLOW_DEFINITION preserved for backward compatibility with older CLI versions

Behavior matrix

Flow	Feature Flag	DEFINITION	CONFIG_ID	SCHEMA_VERSION	FLOW_VERSION
developer/v1	off	developer/v1	developer	v1	2.0.0
developer/v1	duo_developer_next_unstable	developer_unstable/experimental	developer_unstable	experimental	1.0.0
fix_pipeline/v1	off	fix_pipeline/v1	fix_pipeline	v1	1.0.0
fix_pipeline/v1	fix_pipeline_next	fix_pipeline_next/v1	fix_pipeline_next	v1	1.0.0
code_review/v1	—	code_review/v1	code_review	v1	1.0.0
catalog flow (inline config)	—	(as-is)	nil	from params	nil
software_development	—	software_development	nil	nil	nil

Related issues

Closes: #597240 (closed)

Related to: gitlab-org#18785

How to set up and validate locally

1. Spin up your GDK.

2. Trigger the duo developer flow

3. Check the CI job variables — new env vars should be set alongside the existing DUO_WORKFLOW_DEFINITION

   

   

4. Enable duo_developer_next_unstable feature flag

   # gdk rails console
   Feature.enable(:duo_developer_next_unstable)

5. Trigger the developer flow and verify the override produces developer_unstable/experimental with version 1.0.0

   

   

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.