MAINT Extract attack factory constructor compatibility rules

[romanlutz]

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

AttackTechniqueFactory mixes constructor inspection and scoring-configuration compatibility with assembling attack instances. _get_accepted_params, _get_scoring_config_type, _unwrap_optional, _should_apply_scoring_config, and _apply_scorer_policy form a small compatibility subsystem that is harder to understand while mixed into the rest of the factory.

This is F1 of three small factory extractions. It is ready for implementation and does not depend on the adversarial-configuration or converter-composition extractions.

Describe the solution you'd like

Extract the existing constructor-contract inspection and compatibility decisions into a small private, typed helper in the scenario core package. Keep AttackTechniqueFactory as the public entry point and wire the helper into its existing validation and creation paths.

• Represent accepted constructor parameters and the existing scoring-config type contract explicitly rather than repeatedly mixing reflection with configuration assembly.
• Preserve existing type-hint resolution and optional-type handling. Do not broaden supported annotation shapes or introduce a new compatibility policy in this refactor.
• Preserve ScorerOverridePolicy raise/warn/skip behavior, including when a supplied scoring configuration is omitted from constructor arguments.
• Keep configuration compatibility at the technique/factory layer. Do not move it into scorers, targets, or attack algorithms.

Acceptance criteria:

• Factories accept and reject the same constructor/configuration combinations as before.
• Constructor parameter discovery, supported optional annotations, annotation-resolution fallback, and narrowed scoring-config types preserve their existing behavior.
• Missing or incompatible scoring parameters exercise each existing policy with unchanged exceptions/warnings and effective constructor arguments.
• Existing converter-capability checks that depend on constructor parameters still behave identically.
• Public signatures, registered technique behavior, and component identifiers remain unchanged.
• Focused factory coverage exercises the helper through real factory creation as well as its compatibility decisions.

Describe alternatives you've considered, if relevant

Do not introduce a generic dependency-injection/reflection framework or a new public factory API. Avoid splitting each reflection call into a pass-through wrapper. One cohesive contract helper is enough; additional caching is not required.

Additional context

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

This only concerns factory configuration compatibility. It does not refactor scorer execution, observation acquisition/replay, or the generic scorer lifecycle in #2413. The observation-aware LLM scoring proposal is explicitly deferred until reassessment September 29 through October 6, 2026.

#2494 is changing adversarial prompt assembly in the same factory. Keep this extraction confined to constructor compatibility and preserve that work when integrating; do not bundle its prompt changes.

[Kaap10]

Hi Roman Lutz (@romanlutz),

I’d love to take this one on! Since I just wrapped up the GCG phase extractions (#2665), this architectural refactoring is right up my alley.

Proposed Plan:

1. Typed Compatibility Helper: Extract the constructor inspection logic (_get_accepted_params, _unwrap_optional, etc.) and scoring config compatibility rules (_should_apply_scoring_config, _apply_scorer_policy) into a dedicated private, typed helper within the scenario core package.
2. Preserved Invariants:
   • Wire the helper back into AttackTechniqueFactory keeping the public API and registered technique behaviors 100% unchanged.
   • Ensure ScorerOverridePolicy (raise/warn/skip) and type-hint resolution/optional-type handling behave exactly as they do today.
   • Leave the adversarial prompt assembly completely untouched to avoid conflicts with FEAT: add benchmark-owned adversarial prompts #2494.
3. Comprehensive Testing: Add targeted unit tests for the new compatibility helper and verify that all existing factory creation tests pass cleanly without regressions.

If this approach looks good to you, I'd be happy to start working on a PR for this!

[Kaap10]

I have opened PR #2795 to address this.

The constructor compatibility and type-introspection rules have been extracted into _ConstructorCompatibilityHelper with dedicated unit test coverage, while keeping public factory APIs and converter capability checks unchanged.