feat: use create repository branch in resolve_sast_vulnerability

What does this merge request do and why?

• Uses the create_repository_branch to setup a branch to commit/push/open MR from instead of default workflows/ branch
• Adds missing prompt files for claude_3/ for a few prompts
• Updates prompts to specify the new branch / not create a new one.

Reference: https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/issues/1727

How to set up and validate locally

Steps outlined in the original MR: !3664 (merged)

0. Enable GitLab Duo / Agentic flow, enable the import_vulnerabilities feature flag if importing a project from staging/else where.
1. Import a project / or create a SAST vulnerability in a project (export projects can be found here: https://staging.gitlab.com/groups/ai-evaluation/etv with a vulnerability, eg., https://staging.gitlab.com/ai-evaluation/etv/gitlab-runner)

• Check the Secure tab > Vulnerability Report > Filter by report_type SAST

3. Afterwards, navigate to the Project, find the Vulnerability Report, example URL: http://gdk.test:3000/gitlab-duo/myproject/-/security/vulnerability_report/?reportType=SAST
4. Click on a Vulnerability, and grab its ID (at the URL like http://gdk.test:3000/gitlab-duo/myproject/-/security/vulnerabilities/772 so 772
5. Use the ID as part of the request:

export GDK_API_TOKEN=<>

#!/bin/bash

curl -X POST \
-H "Authorization: Bearer $GDK_API_TOKEN" \
-H "Content-Type: application/json" \
-d "{
\"project_id\": \"<PROJECT_ID>\",
\"agent_privileges\": [1, 2, 3, 4, 5],
\"pre_approved_agent_privileges\": [1, 2, 3, 4, 5],
\"goal\": \"<VULN_ID>\",
\"start_workflow\": true,
\"workflow_definition\": \"resolve_sast_vulnerability/v1\",
\"environment\": \"web\",
\"allow_agent_to_request_user\": false
}" \
http://gdk.test:3000/api/v4/ai/duo_workflows/workflows

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.
• If this change requires executor implementation: verified that issues/MRs exist for both Go executor and Node executor or confirmed that changes are backward-compatible and don't break existing executor functionality.