FEAT GUI: Accept exact seed selections in scenario requests

Start with pyrit\models\catalog\scenario.py, pyrit\backend\services\scenario_configuration_resolver.py, the scenario estimate/run services, and pyrit\scenario\core\dataset_configuration.py. Trace how shared estimate and run inputs are resolved, then use the existing framework/model/scenario/database tests to cover exact selections, stale or conflicting references, provenance, read-only estimates, and SQLite/Azure SQL-compatible access.

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

A user selecting a few examples in the explorer must run exactly those examples. Current scenario requests expose dataset names, caps, and a small filter set, not an explicit selected-example contract. Reconstructing a selection from broad filters could run different data.

Work item 13 of 17 in #2744. Technical prerequisites: item 2's stable seed/group IDs and the scorer-preset contract from item 12. Keep not ready yet until promoted.

Describe the solution you'd like

Extend the shared estimate/run models and configuration resolver with a bounded, typed explicit-selection input resolved from existing memory.

• Select complete logical examples by stable references. Resolve canonical content on the backend; do not trust arbitrary browser-supplied file paths or rebuild membership from a dataset name alone.
• Preserve group membership, roles, order, source seed IDs, and existing provenance. Reuse DatasetAttackConfiguration's explicit seed/seed-group input where appropriate.
• Make explicit selection mutually exclusive with conflicting dataset-name/filter/sampling overrides. Do not silently apply a scenario's default cap or random sample to an explicit selection.
• Include the selected configured scorer reference and explicit objective inputs needed by the later scenario adapter, without serializing arbitrary component instances in the request.
• Use the same effective selection/configuration for preview, estimate, and launch. Detect missing, changed, or invalid examples and ask the user to refresh rather than silently dropping rows or expanding to a whole dataset.
• Preserve selected-input provenance using existing scenario/result mechanisms; do not create a new persistent dataset per selection.

Acceptance criteria:

• Selecting N examples yields those same N logical examples in resolution, with linked media intact.
• Invalid/duplicate/missing references and conflicting selection modes have defined, tested behavior.
• Default dataset caps and filters cannot silently change an explicit selection.
• Estimate resolution is read-only and does not fetch providers, persist seeds, or invoke models.
• Existing named-dataset request behavior remains compatible.
• Contract/resolver tests cover mixed examples, stale selection, provenance, and SQLite/Azure SQL-compatible memory access.

Describe alternatives you've considered, if relevant

Do not send an entire dataset to the browser, encode selections as arbitrary Python/opaque dataset_config objects, duplicate selected seeds into a new dataset, or add memory migrations. This item defines/resolves inputs; the scenario implementation is item 14.

Additional context

Start with pyrit\models\catalog\scenario.py, pyrit\backend\services\scenario_configuration_resolver.py, scenario estimate/run services, and pyrit\scenario\core\dataset_configuration.py. DATASET_FILTERS currently exposes harm_categories and data_types; exact selection needs an intentional shared contract. Follow framework/model/scenario/database/test instructions.