FEAT: Support custom scenarios over selected dataset examples

Keep this work blocked until prerequisites 12–13 are promoted. Start with Scenario, DatasetAttackConfiguration, MatrixAtomicAttackBuilder, AttackTechniqueRegistry, ScorerRegistry, and existing matrix-shaped scenarios; read doc\code\framework.md and the scenario/setup-technique/model/test instructions. Done means focused local-fixture tests cover exact selected populations, validation, shared estimates and launch configuration, provenance, progress, results/history, and resume behavior without changing existing scenarios.

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: items 12-13. 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 preset, defaulting to the compatible configured default. 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.
• Read-only estimates and confirmed launch use the same explicit selection and effective 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

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.