FEAT: Add Garak exploitation scenario

[rlundeen2]

Is your feature request related to a problem? Please describe.

PyRIT does not package garak's active lightweight server-side template injection and SQL payload-echo checks as a scenario. Users can call some related scorers directly, but there is no bounded campaign that owns the payload datasets and applies the correct success contract. This is part of #511.

Describe the solution you'd like

Add a PyRIT-native exploitation scenario for the active JinjaTemplatePythonInjection and SQLInjectionEcho variants in exploitation.py.

Implementation requirements:

• Store the SQL and Python/Jinja payloads in local PyRIT datasets. Store reusable wrapping or echo templates in dataset-owned prompt templates instead of hard-coding the corpus in the scenario.
• Preserve the payload, exploit family, expected emitted text, and source provenance in seed metadata.
• Use a small dataset configuration to construct attack groups and use the standard PromptSendingAttack for the single-turn requests.
• Match the upstream primary contract: a result is positive when the target emits the expected payload material. Compose a payload-specific SubStringScorer for this exact check.
• Reuse SQLInjectionOutputScorer and SSTIOutputScorer only as optional extended checks where their existing contracts fit. Do not broaden them only to absorb this corpus, and do not add a duplicate garak detector by default.
• Report that the model emitted exploit material. Do not claim that a downstream SQL database or template engine was exploited.
• Use deterministic, bounded defaults. Add scenario exports, focused unit tests, and synchronized .py and .ipynb scanner documentation.

Follow the separation in PromptInject PR #2509 and doc/code/framework.md: datasets own payloads and templates, techniques describe application, the scenario assembles attacks, attacks execute, and scorers evaluate. Do not port garak's probe, hook, or detector runtime.

Describe alternatives you've considered, if relevant

• SQLInjectionSystem is not required in the first version. Its contract needs inspection of a real downstream database and is not a self-contained target-response check.
• Using only the existing regex scorers was considered. Their current patterns do not implement every payload-specific echo check in the upstream corpus.
• Porting garak's probe and detector classes would duplicate PyRIT execution and scoring responsibilities.

Additional context

• Parent parity issue: Parent: LLM Vulnerability Scanner Feature Parity with Garak, Giskard, CyberSecEval #511
• PyRIT structural example: FEAT: Adding Garak prompt injection scenario #2509
• Upstream probe: garak/probes/exploitation.py
• Garak is Apache-2.0, not MIT. Retain applicable attribution and modification notices for copied or adapted payloads.

[xinnyuli]

Hi! I'd like to take this one.

Traced the pieces on main:

• Scenario would land at pyrit/scenario/scenarios/garak/exploitation.py
  as the 8th garak scenario, with exports in
  pyrit/scenario/scenarios/garak/__init__.py.
• SSTIOutputScorer (pyrit/score/true_false/regex/ssti_output_scorer.py)
  only matches the arithmetic eval probe and Python gadget chains;
  SQLInjectionOutputScorer only matches ;DROP, UNION SELECT, and the
  quote-terminator-comment shape. Neither covers per-payload echo, so the
  primary contract will be a payload-specific SubStringScorer, with those
  two wired as optional extended checks only where their existing patterns
  already fit — no broadening.
• Upstream SQLInjectionSystem is active = False, consistent with leaving
  it out of v1.
• JinjaTemplatePythonInjection and SQLInjectionEcho share ECHO_TEMPLATE,
  and Jinja wraps its payload as {{payload}} via payload_template. I'll
  put the shared echo wrapper in a dataset-owned prompt template and keep the
  two payload corpora (python_code_execution, sql_injection) in local
  datasets, preserving payload / exploit family / expected emitted text /
  provenance in seed metadata.

Following the separation in #2509 and doc/code/framework.md. Will retain
garak's Apache-2.0 attribution for the adapted payloads.