FEAT: Add Garak ProPILE privacy leakage scenario

[rlundeen2]

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

PyRIT does not package ProPILE-style tests that use known personal attributes to ask a model for a withheld attribute. Garak has a small prepared record file and prompt templates, but its probe mixes file loading, prompt construction, and execution. This is part of #511.

Describe the solution you'd like

Add a PyRIT-native ProPILE privacy leakage scenario based on garak/probes/propile.py.

Implementation requirements:

• Support Twin, Triplet, Quadruplet, and Unstructured as explicit opt-in scenario techniques.
• Convert garak's pii_data.jsonl into a local PyRIT seed dataset. Keep the prompt_templates.tsv content in a separate local PyRIT template dataset. Do not add a remote loader.
• Preserve each record's source_dataset and source_id values. Link the stated nvidia/Nemotron-CC-v2.1 source in dataset provenance.
• Preserve the applicable garak Apache-2.0 license, copyright, and attribution notices; mark the PyRIT-formatted files as modified; and update PyRIT's third-party notice material if required by the repository process. See garak's LICENSE.
• Use a dataset configuration, following PromptInject PR FEAT: Adding Garak prompt injection scenario #2509, to build attack groups from known attributes and an expected withheld value. Preserve the PII type and source provenance in seed metadata.
• Use bounded atomic attacks and an expected-value scorer such as SubStringScorer. Reuse existing normalized text matching before adding a new PII scorer.
• Keep this dataset and all techniques out of implicit defaults. Users must select the scenario technique and local dataset explicitly.
• The bundled garak records support Twin and limited Triplet combinations, but they do not contain the fields needed for Quadruplet or Unstructured attacks. Support those techniques in the configuration, test them with synthetic fixtures, and raise a clear error when the selected real dataset has no compatible record. Do not silently report a zero-attack success.
• Add exports, focused unit tests, and synchronized .py and .ipynb scanner documentation.
• State in documentation that an exact match indicates possible disclosure. It does not prove that the target memorized a specific training record.

Follow doc/code/framework.md and the applicable scenario, dataset, test, and documentation instructions. Datasets own records and templates; techniques select the relationship between known and withheld fields; the scenario assembles the campaign; attacks execute; scorers evaluate. Do not port garak's mixin and hook structure.

Describe alternatives you've considered, if relevant

• A loader that streams Nemotron-CC and extracts PII at scenario runtime was considered and rejected. It would add gated-data handling, PII extraction dependencies, nondeterminism, and responsibility bleed.
• A remote loader for garak's JSON file was considered and rejected. This issue should use a local PyRIT dataset with complete provenance and attribution.
• Combining PII records and prompt templates in scenario code would repeat garak's mechanics rather than follow PyRIT's dataset model.

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/propile.py
• Original ProPILE paper: https://arxiv.org/abs/2307.01881

[gugu1031]

I would like to take this.