FEAT Add focused enum and word-selection converter inputs

[Richard Lundeen (richlundeen)]

Description

Add focused registry and GUI support for enum and built-in word-selection inputs, without a general structured-object resolver or broad form rewrite.

• Resolve constructor annotations in their defining namespace, including wrapped and inherited constructors. Preserve unresolved annotations and nullable types.
• Reuse Parameter coercion for enum names, values, existing members, and native numeric values. Keep Binary's strict enum check and distinguish invalid inputs (400) from unexpected constructor errors (500).
• Accept { "type": "random", "parameters": { "proportion": 0.3, "seed": 42 } } and the six other built-in word-selection types. Derive nested controls from backend parameter metadata; do not allow arbitrary class imports.
• Preserve converter defaults, live strategy object identity, and explicit empty lists. Keep file/URL inputs working.
• Include strategy settings in Binary and WordLevel identifiers. Keep selection and negative-index validation in the strategy classes.

Tests and Documentation

• Scoped Python tests: 1,069 passed, 4 skipped across registry, Parameter, affected converters, word-selection strategies, and converter service.
• Related frontend tests: 184 passed across 7 suites.
• TypeScript, production build, scoped ESLint, Ruff, formatting, and ty checks passed.
• Real-backend Playwright flow passed for Binary's default enum input, structured indices, creation, and preview. This run preceded the final nullable/empty-list review fixes; those fixes have unit/component coverage.
• Ran all pre-commit hooks across all files, then all applicable hooks on staged files. All passed except check-added-large-files, whose internal git check-attr call exits 128 in the cached hook environment. A separate size check confirmed all staged files are below the configured 3 MiB limit (largest: 61,091 bytes).
• Updated registry documentation for enum inputs, strategy request shapes, defaults, nullable values, and explicit empty lists. JupyText was not run; no notebook examples changed.

Source branch: richlundeen/PyRIT:richlundeen-focused-converter-inputs. Target: microsoft/PyRIT:main.

[Behnam (behnam-o)]

I left a comment on how I think this fix can be more general and not a special case to handle word selection ... let me know if it doesn't make sense ... I am not against how it looks today if you think the generic solution/suggestion adds more complexity than necessary.

[Behnam (behnam-o)]

[GHCP assisted] Could this be modeled as a generic structured registry input rather than a word-selection special case?

Parameter.word_selection, _STRATEGIES in the shared resolution_custom.py, and the converter-dialog rendering branch couple shared registry/UI infrastructure to one converter concept. The next target, scorer, or scenario needing an allowlisted structured input would likely require the same pattern again.

I prototyped a generic variant contract here: behnam-o@a3b3016. The allowlist remains domain-owned by WordSelectionStrategy, while shared registry and form code handle variant metadata, resolution, and rendering generically. It removes the custom resolver and adds about 121 net production lines. Would you consider this direction?