Add live Scenario progress

[Roman Lutz (romanlutz)]

Summary

Adds the live run dashboard with incremental polling, active/completed/pending attack groups, outcome accounting, elapsed time, ETA, cancellation, and result navigation. Progress cursors are isolated per run so route changes cannot reuse another run's opaque cursor.

What this layer adds

• Incremental polling over lightweight run-bound progress cursors.
• Overall progress plus completed, active, and pending atomic attack groups.
• Group/objective outcome accounting, elapsed time, and ETA.
• Cancellation and navigation to persisted results.
• Cursor reset when the routed Scenario result changes.

Preview

Stack

This is 3 of 7 in native GitHub Stack #2390 and depends on #2373.

Layer	Scope	Pull request
1	Progress foundation	#2372
2	Catalog and launch	#2373
3	Live progress (this PR)	#2374
4	Run history	#2375
5	FIFO scheduling	#2376
6	Configuration sizing	#2377
7	Result details	#2378

See the full implementation, screenshots, walkthrough, validation, and operational notes.

Validation

• Backend: 15,212 passed, 120 skipped.
• Frontend: 68/68 suites, 1,286/1,286 tests; lint, TypeScript, and production build passed.
• Mock E2E, retries disabled: 91 passed, 0 failed, 0 skipped.
• Seeded E2E, retries disabled: 62 passed, 0 failed, 0 skipped.
• All configured pre-commit hooks passed; distinguished-engineer review approved the final stack.

[Behnam (behnam-o)]

This PR should be scoped to the frontend live-progress experience; no changes under /pyrit are needed here. The progress and cancellation backend APIs come from earlier stack layers, ScenarioRunPlanGroupKind is only consumed by #2378, and the dataset-size override contract is first consumed by #2377. Moving those backend changes to their corresponding follow-up PRs would keep this layer focused and independently reviewable.

[Behnam (behnam-o)]

Could we move this enum and group_kind field to the later PR that actually introduces multiple group kinds? In this PR the enum has only ATTACK, and the field is only persisted—not consumed—so it adds a discriminator without distinguishing anything. If this needs to land here for forward compatibility with the stacked changes, it would help to include the upcoming values or otherwise make that dependency explicit.

[Behnam (behnam-o)]

Could we move this dataset-sizing contract to #2377, where it is first consumed? The live-progress work in this PR does not use DATASET_SIZE_LIMIT_OVERRIDE_SCOPE or get_dataset_size_limit_override_scope; #2377 wires it into the scenario registry and adds the scenario-specific overrides. Keeping it there would make this PR frontend-only and keep the backend sizing change with its actual behavior.