MAINT Decompose ScenarioDetail launch and estimate state

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

`frontend/src/components/Scenarios/ScenarioDetail.tsx` owns scenario/target loading, retry and error states, technique and aggregate-tag selection, dataset overrides and filters, dynamic parameter values, run-request validation, debounced estimates, stale-estimate suppression, launch confirmation, duplicate-submit prevention, and the complete form UI.

The request builders are already mostly pure, but the surrounding estimate and launch state spans many independent `useState`, `useMemo`, `useEffect`, and ref guards. This makes it difficult to verify that preview, estimate, validation, and launch all use the same effective configuration and that asynchronous results cannot overwrite newer input.

#### Describe the solution you'd like

Extract cohesive data and workflow boundaries while retaining `ScenarioDetail` as the page-level composition component. Candidate boundaries include:

- a data-loading hook for scenario and target loading, retry, not-found, and error states;
- a typed launch-form reducer or hook for target, techniques, baseline, datasets, filters, concurrency, retries, and dynamic parameters;
- an estimate hook responsible for debounce, request identity, cancellation/stale-response suppression, and estimate state;
- a launch hook responsible for confirmation, request submission, duplicate-submit prevention, and API errors;
- smaller presentational sections for target, technique, dataset, dynamic-parameter, estimate, and confirmation UI.

Keep `buildEstimateRequest` and `buildRunRequest` pure and ensure both consume the same typed effective form state. Do not duplicate normalization or validation across hooks and components.

Preserve route behavior, request payloads, defaults, baseline constraints, technique-tag semantics, dataset parsing, dynamic parameter handling, estimate debounce timing, stale-request protection, confirmation flow, duplicate-submit protection, accessibility, and user-visible errors.

#### Describe alternatives you've considered, if relevant

Extracting only the form sections would shorten the JSX but leave asynchronous estimate and launch ownership coupled. Moving every state variable into one large hook would move the complexity without making transitions explicit. A reducer is most useful for related form fields; loading, estimation, and submission should remain separate workflows.

#### Additional context

This was identified during the September 14, 2026 maintainability audit. A repository issue search found no exact existing tracker.

Suggested regression coverage:

- scenario/target load success, retry, not-found, and failure;
- technique, aggregate-tag, and baseline selection rules;
- dataset overrides, filters, dynamic parameters, and default maximum size;
- estimate debounce and stale-response suppression after rapid changes;
- parity between preview/estimate input and final run request;
- invalid request states and user-visible errors;
- confirmation cancellation and successful launch;
- two launch attempts in the same tick creating only one request;
- effect cleanup during navigation/unmount.

Definition of done:

- loading, form state, estimation, and submission have explicit typed ownership and focused tests;
- estimate and launch use one canonical effective form state;
- `ScenarioDetail` primarily composes the page and presentational sections;
- no route, backend API, accessibility, or user-visible behavior changes;
- frontend unit tests, type-check, lint, and formatting pass.