Fix pipeline flow creates duplicate merge requests

Summary

When running the Fix Pipeline flow (duo_workflow_service/agent_platform/v1/flows/configs/fix_pipeline_next/1.0.0.yml), two merge requests are produced for a single session: one is created somewhere along the create_plan path (which is not meant to create an MR at all), and a second one is created at the end by the dedicated fix_pipeline_next_create_new_mr component.

Root cause analysis

The fix_pipeline_next_execution component (the first agent step reached via create_plan) is configured with:

toolset:
  - create_file_with_contents
  - edit_file
  - find_files
  - mkdir
  - read_file
  - run_command

The run_command tool can execute arbitrary shell commands, including glab commands. The execution step's user prompt (ai_gateway/prompts/definitions/fix_pipeline_next_execution/user/1.0.0.jinja) explicitly tells the agent to:

Use the run_command tool to verify that your fixes work. […] Run the same commands that failed in the pipeline to verify they now pass.

Combined with the project's AGENTS.md content (passed into the system prompt via agents_dot_md/base/1.0.0.jinja), which talks about Fix Pipeline MRs, labels, and triggers, the model is nudged toward MR-creating behavior.

Proposed fix

Tighten the fix_pipeline_next_execution prompt at ai_gateway/prompts/definitions/fix_pipeline_next_execution/system/1.0.0.jinja to explicitly forbid MR-side effects via run_command. Add a guideline such as:

<execution_guidelines>
  ...
  <guideline>Do NOT create, update, or comment on merge requests. Do NOT run any `glab` commands, GitLab API calls, or `git push`. Merge request creation is handled by a later step.</guideline>
  <guideline>`run_command` is for local verification only (running tests, linters, build steps that mirror CI). It must never produce remote side effects.</guideline>
</execution_guidelines>