MAINT Extract attack factory converter configuration composition

[romanlutz]

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

AttackTechniqueFactory.create() handles both complete converter-configuration overrides and additive request-converter composition alongside unrelated scoring and adversarial setup. The distinction matters: selecting extra request converters must not discard a technique's built-in behavior or its response converters.

This is F3 of three small factory extractions. It is ready for implementation and can land without the other factory extractions.

Describe the solution you'd like

Extract the existing converter-composition rules into a small private, typed helper at the technique layer. Have the factory use it while preserving its public parameters and current behavior.

• Keep full configuration replacement distinct from additive request-converter composition.
• Preserve the existing ordering between the selected base request pipeline and extra request converters.
• Preserve the response-converter pipeline from the effective base configuration.
• Retain the explicit supports_additional_request_converters capability and existing constructor checks. A constructor accepting a converter parameter alone does not imply semantic support for additive composition.
• Do not mutate the registered factory's stored configuration or caller-supplied converter lists during composition.

Acceptance criteria:

• No override and no extras preserve the technique's original behavior.
• A full override retains current replacement semantics, including an explicitly empty configuration.
• Extras with and without an override preserve current request order and response converters.
• Unsupported additive composition and invalid capability declarations retain their existing validation/error behavior.
• Repeated factory creation with different extras does not accumulate converters or alter the original inputs.
• Public signatures, component identity, and existing registered technique behavior remain unchanged.
• Focused factory coverage verifies the composition matrix and the actual configuration passed to the attack constructor.

Describe alternatives you've considered, if relevant

Do not move converter execution into the factory, implement a second converter pipeline in the backend/UI, or create a generic configuration framework. Keep one clear internal composition helper and reuse the existing configuration types.

Additional context

Starting points: pyrit/scenario/core/attack_technique_factory.py, AttackConverterConfig, ConverterConfiguration, and tests/unit/scenario/core/test_attack_technique_factory.py. Follow doc/code/framework.md and the scenario, Python, and test instructions.

Related consumer: #2758 will expose registered techniques and ordered extra converters in the GUI. This extraction preserves the contracts it consumes and does not implement that GUI issue; #2758 is not a prerequisite for this refactor. Coordinate with #2494 where the same factory file is edited, but leave adversarial prompt assembly out of this change.

[ahcrm-core]

Hi, I’d like to take this issue. I reviewed the acceptance criteria and the current composition logic in AttackTechniqueFactory.create(). I plan to extract a small typed helper, preserve replacement versus additive semantics, converter ordering, response converters, capability validation, and input/factory immutability, with focused matrix tests. I also noticed that #2494 currently touches the same factory file. Should I proceed from current main and rebase after #2494, or wait for that PR to settle first?