FEAT GUI: Configure scenario attack techniques and converters

Start with ScenarioDetail and the form boundaries from #2653, then read ScenarioConfigurationResolver.resolve_techniques_and_converters(), AttackTechniqueFactory’s converter-composition support, and the existing converter registry/API controls. Trace the typed configuration through preview, estimate, confirmation, and launch. Done means the listed UI/service tests cover defaults, ordering, invalid combinations, stale estimates, and duplicate-baseline prevention.

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

The selected-example scenario should support standard attack techniques and converter options after its basic prompt-sending flow works. The existing Scanner form does not expose technique_converters, although the backend has registry-backed converter composition.

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 shared scenario configuration UI with compatible registered technique choices and ordered additional converter pipelines. Keep prompt sending and no additional converters as the 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

Start with ScenarioDetail and the form boundaries from #2653, ScenarioConfigurationResolver.resolve_techniques_and_converters(), AttackTechniqueFactory's converter-composition support, and the existing converter registry/API controls. Follow framework, frontend, scenario, converter, and test instructions for touched files.