Bind workflow tokens to catalog flow config

What does this MR do and why?

Passes the Rails-authorized catalog flow configuration to DWS when minting a workflow token, allowing DWS to reject inline configuration substitution. Existing non-catalog callers are unchanged.

Resumed catalog workflows now keep the flow version they were started with instead of resolving the consumer's pinned version again, so a catalog release published mid-workflow cannot change the config of a checkpointed run.

Related #2432

References

• Issue: https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2432
• DWS integration: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!6702 (merged)

DWS/Rails Compatibility

Rails	DWS	Workflows	Substitution blocked
Old	Old	Work	No
Old	New	Work	No; tokens remain unbound
New	Old	Work	No; the optional protobuf field is ignored
New	New	Work	Yes

Either MR can deploy first. During a rolling DWS deployment, protection applies only when a new instance both mints and handles the token. Rejecting missing digest claims must wait until both rollouts finish.

Screenshots or screen recordings

Not applicable. This change has no UI.

How to set up and validate locally

With GDK running this Rails branch and the linked DWS branch:

Create a personal access token with the api scope, then set the required variables:

export GITLAB_URL="http://gdk.test:3000"
export GITLAB_TOKEN="<personal-access-token-with-api-scope>"
export PROJECT_ID="<numeric-project-id>"
export CONSUMER_ID="<catalog-item-consumer-id>"
export GOAL="Create hello.txt containing hello"

1. Enable a custom AI Catalog flow for a test project and obtain its consumer ID.

2. Start the flow through the API:

   curl --request POST \
     --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
     --header "Content-Type: application/json" \
     --data "{
       \"project_id\": \"$PROJECT_ID\",
       \"ai_catalog_item_consumer_id\": \"$CONSUMER_ID\",
       \"goal\": \"$GOAL\",
       \"start_workflow\": true
     }" \
     --url "$GITLAB_URL/api/v4/ai/duo_workflows/workflows"

3. Confirm the workflow pipeline starts normally.

4. Run the linked DWS server test with a modified inline flowConfig and confirm DWS returns PERMISSION_DENIED before flow resolution.

MR acceptance checklist

• Targeted service and client specs pass.
• The vendored DWS client is updated to 0.13.
• Existing token callers remain backward-compatible.
• Rebased and regenerated the vendored client after the foundational-flow contract MR (!253227 (merged)) merged.