feat: use flow registry for fix_pipeline

What does this merge request do and why?

In the first MR, the fix_pipeline flow was basically a copy of the issue_to_merge_request, with a different toolset and modified prompts. This MR converts the fix_pipeline flow to use the new Flow Registry DSL.

Closes gitlab-org/gitlab#557910 (closed)

How to set up and validate locally

Note: I've tested this for simple pipeline failure, like linting issues, and it seems to work well. For example, I cloned the AI Gateway repo into my local GDK, and then had the pipelines only run linting, and reordered packages in a file. This fails the isort check, and is easy for the agent to fix.

1. Setup your remote execution environment in GDK by following instructions here
2. Create a failing job in your GDK, within a Merge Request.
3. Get the URL for the failing job, and the branch for the MR
4. Run the below curl command:

curl --location 'http://gdk.test:3000/api/v4/ai/duo_workflows/workflows' \
    --header 'Content-Type: application/json' \
    --header "PRIVATE-TOKEN: $PAT" \
    --data '{
        "project_id": "22",
        "goal": "FAILING_JOB_URL",
        "workflow_definition": "fix_pipeline/experimental",
        "agent_privileges": [1,2,3,5],
        "pre_approved_agent_privileges": [1,2,3,5],
        "start_workflow": true,
        "allow_agent_to_request_user": false,
	"source_branch": "BRANCH_FOR_YOUR_MR_HERE"
}'

4. Go to pipelines (Build > Pipelines) and see the running flow.
5. When the workflow job is completed, you should see a new Merge Request with an additional commit attempting to fix the failing job.

Graph Structure

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.