FIX: Show only supported scenario inputs in scanner forms

[Richard Lundeen (richlundeen)]

Description

The scanner form showed common input fields for every scenario, even when a scenario explicitly removed those inputs from supported_parameters(). Users could enter values that the scenario could not accept, causing estimate or launch failures.

For example, Garak Exploitation (garak.exploitation) uses a fixed reference corpus and excludes dataset_config. However, its GUI still showed Dataset override, Max dataset size, Harm categories, and Data types. These request fields all map to the unsupported dataset_config input.

This fix makes controls, validation, previews, and estimate/launch requests follow each scenario's declared inputs. Hidden inputs and stale unsupported drafts are not submitted. The catalog exposes supported_parameter_names from all declarations because the existing typed supported_parameters list excludes opaque inputs such as dataset_config. Omitted common inputs also stay omitted through launch and resume.

Related: #3118 adds technique.execute, which also excludes dataset configuration. This PR fixes the generic GUI issue for all scenarios. The separate one-technique selection rule remains in #3118.

[Roman Lutz (romanlutz)]

Must Fix: Preserve the effective defaults for nullable retry/concurrency inputs

RunScenarioRequest now accepts max_concurrency: null and max_retries: null. Preparation treats these values as omitted, so the scenario uses its declared defaults, but _initialize_scenario_async saves the original null values. This check then prevents that run from resuming after a failure.

For example, this is now a valid launch request:

{"scenario_name": "garak.exploitation", "target_name": "my_target", "max_retries": null}

I reproduced the save/resume path with a real scenario registry and SQLite: the resolved retry count was 0, the saved retry count was null, and POST /api/scenarios/runs/{id}/resume returned HTTP 409 with "The saved launch configuration is incomplete". Omitting the field resumed successfully.

Could we save the resolved numeric values when these inputs are supported, while keeping None for unsupported inputs? A real save/resume regression test for each nullable field would catch this.

Location: scenario_run_service.py:341-347