MAINT Extract attack factory constructor compatibility rules

Start with pyrit/scenario/core/attack_technique_factory.py and tests/unit/scenario/core/test_attack_technique_factory.py, following doc/code/framework.md and the scenario, Python, and test instructions. Trace the listed constructor-inspection and scoring-compatibility methods through real factory creation. Done means the helper preserves existing type-hint, optional, policy, converter-check, signature, identifier, and factory behavior, with focused coverage.

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.