FEAT: Support custom scenarios over selected dataset examples #2760

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

The explorer's multi-select flow needs an ordinary scenario over exactly the selected examples, defaulting to prompt sending. Reusing another scenario's defaults could unexpectedly add techniques, sample away selections, or run prompt sending twice as both a technique and baseline.

Work item 14 of 17 in #2744. Technical prerequisites: the general scorer registry API in #2755 (completed in #2990) and the exact-selection/scorer-reference contract in #2757. Keep not ready yet until promoted.

Describe the solution you'd like

Add the smallest registered scenario/configuration adapter needed for explicit selected examples. Reuse Scenario, existing attack techniques/factories, atomic attack construction, scorer registry resolution, and normal scenario progress/results/history.

• The default effective attack is exactly prompt sending with no additional converters. Do not fall back to another scenario's default technique set or emit a duplicate baseline for the same population.
• Accept a compatible configured objective scorer by the registry-name contract in FEAT GUI: Accept exact seed selections in scenario requests #2757. For an implicit default, prefer the compatible configured instance tagged default_objective_scorer and reuse the existing scenario/core default-selection policy. A missing or incompatible explicit choice must not silently select a different scorer. Missing/unusable defaults or prerequisites must have defined behavior and actionable setup guidance, never an incompatible or unscored run.
• Reuse configured composites and inverters where appropriate. Catalog membership, a class name, or a true_false result family alone does not prove objective compatibility. Keep scorer-specific checks in shared scorer/registry/core policy; backend models and services adapt that policy rather than creating another compatibility table.
• Preserve objective-result meaning: raw refusal=true means refusal, not attack success. Use appropriate existing inverter/composite semantics. raise_if_scorer_blocks concerns the scoring target blocking a judging request; it is not a refusal-result polarity switch.
• Require valid objectives; preserve source objectives and accept explicit user-supplied objectives for examples that need them instead of inventing goals.
• Resolve explicit selections through the contract from item 13. Retain group boundaries, roles, multimodal content, and provenance. Explain unsupported seed shapes rather than flattening templates or simulated configuration into text.
• Expose supported registered techniques and converter-composition seams for the later UI. Attacks/converters/scorers keep their normal responsibilities; the scenario packages them and owns execution orchestration.
• Use registry-compatible construction and metadata introspection without fetching datasets or generating conversations. Validate execution prerequisites at the appropriate run/setup boundary.

Acceptance criteria:

• N valid selected examples with default settings produce exactly N prompt-sending executions, not N plus an extra baseline/default attack set.
• Missing objectives/scorers, incompatible modalities/techniques, and invalid groups produce actionable validation errors.
• Tagged compatible defaults, non-default explicit choices, configured composites/inverters, and raw-refusal semantics are covered by focused tests.
• Empty registries, missing/incompatible defaults, missing scorer dependencies, unknown/stale requested names, and registry reinitialization have defined errors or setup guidance without silently replacing an explicit selection.
• Read-only estimates and confirmed launch use the same explicit selection and effective configured scorer, target, and technique configuration.
• Normal scenario progress, results/history, and supported resume behavior preserve the selected population and provenance.
• Existing scenarios' defaults and named-dataset behavior do not change.
• Focused scenario/service tests use local fixtures and fake targets/scorers, with no paid calls.

Describe alternatives you've considered, if relevant

Do not create a GUI-specific batch executor, generate Python scenario classes from user text, add an unscored mode, or redesign memory. Avoid adding a duplicate global prompt-sending factory merely to work around baseline semantics.

Additional context

This item retains the objective-compatibility, default-selection, and result-polarity requirements from the original #2755. #2990 completed the general registry API, not these dataset-scenario behaviors. Expose shared policy results for the picker in #2759 without moving scorer business logic into HTTP DTOs or the browser.

Start with Scenario, DatasetAttackConfiguration, MatrixAtomicAttackBuilder, AttackTechniqueRegistry, ScorerRegistry, and existing matrix-shaped scenarios as patterns. The core technique catalog intentionally omits bare prompt sending because it is normally a baseline; handle the custom scenario's default deliberately. Read doc\code\framework.md and scenario/setup-technique/model/test instructions.

Relationship to scenario dataset generation

The scenario dataset plan is complementary: it supplies generated named data and shared source/preparation behavior, while this adapter runs exactly the stored examples selected in the explorer. Source/limit preparation (#2956) and configured providers (#3116) are already merged. The still-open #3143 adds scenario-owned dataset options and shared wire settings. Reuse those framework seams where applicable; do not build a second preparation lifecycle or generic scenario runner.

This adapter's input population remains the exact selection resolved by #2757. Current generic attack configuration defaults can cap named sources at five each or inline inputs at five total. Configure the selected-input path deliberately so neither cap, random sampling, or named-source overrides change N selected examples; null/default is not an uncapped value. Missing or changed selected records must fail rather than invoking a configured provider to generate replacements.

Generated SeedObjective rows are ordinary stored objectives here. Preserve them and their provenance; examples missing a required objective still need the user's explicit input, not automatic objective generation. The scorer in this issue judges the attack outcome. Scoring generation quality, configuring a generation target, and destructive dataset refresh are separate optional features, not new prerequisites or deliverables for this adapter. Existing release gates remain unchanged.