FEAT GUI: Configure scenario attack techniques and converters #2758

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

The selected-example scenario needs compatible techniques and ordered extra converter options after its prompt-sending default flow works. Scanner already has technique selection and a shared single-technique TechniqueEditor with request/response converter chains. Its general multi-technique launch form still hides the opaque technique_converters parameter. The missing work is selected-scenario integration/per-technique additive composition, not another technique or converter editor.

Work item 16 of 17 in #2744. Technical prerequisites: items 12-15. Keep not ready yet until promoted.

Describe the solution you'd like

Extend the existing shared Scenario form for the selected-example consumer. Reuse TechniqueEditor, ConverterChainField, useRunTechniqueEditor, the converter/technique catalogs, and backend token/composition resolution. Add only the compatible per-technique additive mapping/default-path integration still missing. Keep prompt sending and no additional converters as defaults.

• Use the existing technique and converter registries. Show descriptions and required dependencies; do not hardcode attack classes or accept arbitrary Python configuration.
• Preserve converter order and its association with the intended technique. Distinguish technique-owned converters from extra converters chosen here; selecting no extra converters must not strip a technique's built-in behavior.
• Wire chosen converters into the prompt-sending path as well as supported additional techniques. Do not accidentally apply them only to non-baseline attacks.
• Honor factory support for additional request converters, target modality support, required adversarial targets, and scorer requirements. Explain incompatible combinations without silently skipping selected work.
• Keep preview, estimate, confirmation, and final run request based on one typed effective configuration. Show the planned execution count and avoid an accidental duplicate prompt-sending baseline.

Acceptance criteria:

• The untouched form still runs only prompt sending with no additional converters.
• Selecting compatible techniques and ordered converters produces the intended registry-backed configuration.
• Converter ordering and per-technique mapping survive edits and are identical in estimate and launch.
• Missing dependencies and unsupported composition/modality combinations have clear validation.
• Existing Scanner defaults and other scenarios' baseline policies remain intact.
• UI/service tests cover default behavior, configuration changes, stale estimates, invalid combinations, and duplicate-baseline prevention.

Describe alternatives you've considered, if relevant

Do not execute converters in the browser, reimplement attack algorithms in the backend, build an arbitrary scorer/attack editor, or duplicate the launch form. Reuse registered instances and existing composition contracts.

Additional context

Scope refreshed against main 791e12c6e5e4302e7c1211af6af8973aa6fe1f37 on October 31, 2026. Start with ScenarioDetail, existing #2653/#3526 form decomposition, shared technique/converter editors, ScenarioConfigurationResolver.resolve_techniques_and_converters(), and AttackTechniqueFactory's additive composition support. Run-local technique-owned converter settings and additional per-technique converters are different; do not overwrite the former while adding the latter. Follow framework, frontend, scenario, converter, and test instructions. No readiness promotion is implied.